From nobody Mon Feb 2 09:46:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BD21A87D4 for ; Mon, 2 Feb 2015 09:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx6O5y7ST7MW for ; Mon, 2 Feb 2015 09:46:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA251A87CB for ; Mon, 2 Feb 2015 09:46:18 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.75.20; Mon, 2 Feb 2015 17:45:54 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.196]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.196]) with mapi id 15.01.0075.002; Mon, 2 Feb 2015 17:45:54 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] draft-ietf-netconf-call-home-03.txt Thread-Index: AQHQMdNqjeGCbrIRk0K/2wI+9zdOR5zDHsaAgASDHtKABl92AIAPZ1cA Date: Mon, 2 Feb 2015 17:45:54 +0000 Message-ID: References: <201501162128.t0GLSn2W060604@mainfs.snmp.com> <201501191612.t0JGCgKk010289@mainfs.snmp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.12] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 0475418F50 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(24454002)(43784003)(41574002)(164054003)(51704005)(377454003)(479174004)(77156002)(46102003)(62966003)(575784001)(450100001)(2900100001)(106116001)(122556002)(99286002)(87936001)(2656002)(36756003)(551544002)(66066001)(50986999)(76176999)(54356999)(86362001)(110136001)(102836002)(83506001)(2950100001)(19580405001)(107886001)(2351001)(2501002)(15975445007)(93886004)(230783001)(40100003)(19580395003)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <383F92B8BAEA4843A873F8E1F97361CB@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2015 17:45:54.1470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:46:22 -0000 Hi All, No one disapproved of the change discussed below last week, so I'll close #11 and post a -04 in just a little bit. Cheers, Kent On 1/23/15, 5:32 PM, "Kent Watsen" wrote: > > >Hi Alan, > >Thanks again for your comments! > > >>>>Section 3.2, third paragraph: >>>>----------------------------- >>>> >>>>Would it be appropriate to change "credentials" to "identity"? This is >>>>the=20 >>>>only paragraph where the term "credentials" is used. >>>> >>>>When I saw "credentials", I thought of something like a password, host >>>>key,=20 >>>>or X.509 cert, rather than simply the server's identity. If changing >>>>"credentials" to "identity" is not appropriate, then perhaps adding one >>>>sentence that defines the term credentials. >>> >>>We could say "verify identity" as well. Think of the questions the >>>client >>>is asking: >>> >>> - who is trying to connect to me? (identity) >>> - how do I know that it is really you? (verify identity) >>> >> >>Thanks! This explanation makes very good sense. These were not obvious >>to me upon a first read of the document. >> >>I think other new readers of the document would benefit if this >>explanation >>could be shoe-horned into the existing text, but I wouldn't delay the >>document to add it. > > >I opened issue #11 to track this change: > > https://github.com/netconf-wg/call-home/issues/11 > >I think this is a "minor" issue, needing WG review, but not needing a lot >of discussion. Hence I went ahead and modified the text (see diff below) >and moved the issue to the "Review" state. > > =20 >https://github.com/netconf-wg/call-home/commit/cd4a5f674d7e57a06d7cd0dc8d1 >b >153d72a573a3 > > > >If no one disapproves of this change next week, I'll submit a -04 draft >incorporating it then. Last-call is close! > >Thanks, >Kent > >=20 > > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Feb 2 10:07: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 C6E191A8832; Mon, 2 Feb 2015 10:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ0kG11GaVIb; Mon, 2 Feb 2015 10:07:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 794681A8836; Mon, 2 Feb 2015 10:07:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150202180716.15566.30013.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 10:07:16 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:07:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-04.txt Pages : 13 Date : 2015-02-02 Abstract: This document presents NETCONF Call Home and RESTCONF Call Home, which respectively enable a NETCONF/RESTCONF server to initiate a secure connection to a NETCONF/RESTCONF client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-call-home-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 2 10:18:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108691A8862 for ; Mon, 2 Feb 2015 10:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgHOokofMV5c for ; Mon, 2 Feb 2015 10:18:51 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99181A8857 for ; Mon, 2 Feb 2015 10:18:45 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.75.20; Mon, 2 Feb 2015 18:18:22 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.196]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.196]) with mapi id 15.01.0075.002; Mon, 2 Feb 2015 18:18:22 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-04.txt Thread-Index: AQHQPxMjarxRCmHZw0qwWdFU+UYYwpzdV0WA Date: Mon, 2 Feb 2015 18:18:21 +0000 Message-ID: References: <20150202180716.15566.30013.idtracker@ietfa.amsl.com> In-Reply-To: <20150202180716.15566.30013.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.12] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-prvs: 0475418F50 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(164054003)(479174004)(377424004)(377454003)(51704005)(83506001)(110136001)(106116001)(122556002)(40100003)(2351001)(107886001)(92566002)(19580405001)(1720100001)(19580395003)(86362001)(66066001)(2656002)(87936001)(2950100001)(2900100001)(46102003)(54356999)(50986999)(2501002)(99286002)(36756003)(77156002)(230783001)(76176999)(62966003)(15975445007)(450100001)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2015 18:18:21.9347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:18:53 -0000 As captured in the change log, the only update in -04 is: o Replaced "verify credentials" with "verify identity" (issue #11) With this update, all known issues are closed. Thanks, Kent On 2/2/15, 1:07 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Call Home and RESTCONF Call Home > Author : Kent Watsen > Filename : draft-ietf-netconf-call-home-04.txt > Pages : 13 > Date : 2015-02-02 > >Abstract: > This document presents NETCONF Call Home and RESTCONF Call Home, > which respectively enable a NETCONF/RESTCONF server to initiate a > secure connection to a NETCONF/RESTCONF client. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-call-home-04 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Feb 2 10:39:31 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 692BC1A87B8 for ; Mon, 2 Feb 2015 10:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL6H2gzhFeCW for ; Mon, 2 Feb 2015 10:39:28 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6A21A878A for ; Mon, 2 Feb 2015 10:39:28 -0800 (PST) Received: from CO2PR05CA039.namprd05.prod.outlook.com (10.141.241.167) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 2 Feb 2015 18:39:28 +0000 Received: from BY2FFO11FD048.protection.gbl (2a01:111:f400:7c0c::166) by CO2PR05CA039.outlook.office365.com (2a01:111:e400:1429::39) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Mon, 2 Feb 2015 18:39:27 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD048.mail.protection.outlook.com (10.1.15.176) with Microsoft SMTP Server (TLS) id 15.1.75.11 via Frontend Transport; Mon, 2 Feb 2015 18:39:26 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 2 Feb 2015 10:35:26 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t12IZHW42088 for ; Mon, 2 Feb 2015 10:35:22 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t12IZ2ap027185 for ; Mon, 2 Feb 2015 13:35:03 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502021835.t12IZ2ap027185@idle.juniper.net> To: In-Reply-To: <20150131043354.17295.24489.idtracker@ietfa.amsl.com> Date: Mon, 2 Feb 2015 13:35:02 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(48376002)(77096005)(50466002)(105596002)(86362001)(6806004)(47776003)(107886001)(2351001)(110136001)(106466001)(230783001)(92566002)(46102003)(2950100001)(76506005)(53416004)(19580405001)(19580395003)(50986999)(54356999)(87936001)(62966003)(77156002)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB440; X-Forefront-PRVS: 0475418F50 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2015 18:39:26.2586 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-yang-library-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:39:30 -0000 internet-drafts@ietf.org writes: > Title : YANG Module Library > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Filename : draft-ietf-netconf-yang-library-00.txt The concept of "conformace" here is still not compatible with my understanding of YANG's import statement. Since importing a statement doesn't mean one implements the module, it's not proper to announce modules one doesn't implement (viewed here a "conformance false" modules) via , so it wouldn't make sense here either. Thanks, Phil From nobody Mon Feb 2 10:48: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 AE6B51A893A for ; Mon, 2 Feb 2015 10:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR0Od5S1-_SR for ; Mon, 2 Feb 2015 10:48:15 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1DB1A8935 for ; Mon, 2 Feb 2015 10:48:14 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id gm9so44129556lab.0 for ; Mon, 02 Feb 2015 10:48:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ou5LfsfYjsZft6atq2OogcbF3204OIc7wbrahW0zVtE=; b=iDMxJbN2v+aJm7kxC5RXWyx8lkoEeYoI1CmELQyABDpqHdprCwrCPBFUdeg3hMm0jf Ja66ew7OrWZ1HMe/X0MhJvnzGqY9a53r9aHb+/RLoclTAS/MHKSnUTaNTgK3TUJDgHWw mPGXvTt0aN98Hj5yNXpViFjudi5A2623nfdfo6uAvwCCFjYlQS868Focq6/WheeA8FAp 1+KDaokxYccYfqihrDhp6H5Xtk+xUyU4Eai2dZ98rWY4vaTskVtM8PKgMFCgpLeU60sR DZF+GV7eBSbROtx/PZ7Natdea8eKW23vzEQqdwu0gINhXb3usRDgqF2GcY6oYdsGwt8b sQqA== X-Gm-Message-State: ALoCoQmfx3IyMmuhIMLlpZRdWl7I8lVIGZuo/1TXk48tS0ROTYwGgBO2FRUGkoRTuSBD3ABapCOi MIME-Version: 1.0 X-Received: by 10.112.137.38 with SMTP id qf6mr3510595lbb.59.1422902893056; Mon, 02 Feb 2015 10:48:13 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 2 Feb 2015 10:48:13 -0800 (PST) In-Reply-To: <201502021835.t12IZ2ap027185@idle.juniper.net> References: <20150131043354.17295.24489.idtracker@ietfa.amsl.com> <201502021835.t12IZ2ap027185@idle.juniper.net> Date: Mon, 2 Feb 2015 10:48:13 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-yang-library-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:48:16 -0000 On Mon, Feb 2, 2015 at 10:35 AM, Phil Shafer wrote: > internet-drafts@ietf.org writes: >> Title : YANG Module Library >> Authors : Andy Bierman >> Martin Bjorklund >> Kent Watsen >> Filename : draft-ietf-netconf-yang-library-00.txt > > The concept of "conformace" here is still not compatible with my > understanding of YANG's import statement. Since importing a statement > doesn't mean one implements the module, it's not proper to announce > modules one doesn't implement (viewed here a "conformance false" > modules) via , so it wouldn't make sense here either. > I would be OK with removing the 'conformance' leaf and not mentioning it at all (open issue #1). Import-by-revision is not used everywhere. IMO this is good because it can be complex and doesn't really work wrt/ multiple revisions of protocol-accessible objects. Since the revision dates for imports are rarely available, clients need to retrieve them from the server, or get them from the . > Thanks, > Phil Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Feb 2 11:30:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48AB1A1A6A for ; Mon, 2 Feb 2015 11:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTvPFpNWhISC for ; Mon, 2 Feb 2015 11:30:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0F33A1A1A3D for ; Mon, 2 Feb 2015 11:30:35 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F7DD1280A44; Mon, 2 Feb 2015 20:30:33 +0100 (CET) Date: Mon, 02 Feb 2015 20:33:57 +0100 (CET) Message-Id: <20150202.203357.2240513349527110616.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201502021835.t12IZ2ap027185@idle.juniper.net> References: <20150131043354.17295.24489.idtracker@ietfa.amsl.com> <201502021835.t12IZ2ap027185@idle.juniper.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-yang-library-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 19:30:36 -0000 Phil Shafer wrote: > internet-drafts@ietf.org writes: > > Title : YANG Module Library > > Authors : Andy Bierman > > Martin Bjorklund > > Kent Watsen > > Filename : draft-ietf-netconf-yang-library-00.txt > > The concept of "conformace" here is still not compatible with my > understanding of YANG's import statement. Since importing a statement > doesn't mean one implements the module, it's not proper to announce > modules one doesn't implement (viewed here a "conformance false" > modules) via Agreed. > so it wouldn't make sense here either. Disagree. Unless import-by revision is used everywhere (it is not), this can be useful (see solution P1b-01 in draft-bjorklund-yang-conformance-problem-00). There are other ways of solving this as well (see the draft). /martin From nobody Mon Feb 2 11:49: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 C9B541A89E1; Mon, 2 Feb 2015 11:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NyKJKy_vBG1; Mon, 2 Feb 2015 11:49:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DCF1A893F; Mon, 2 Feb 2015 11:49:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150202194924.24680.16859.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 11:49:24 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-server-model-06.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: Mon, 02 Feb 2015 19:49:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Server and RESTCONF Server Configuration Models Authors : Kent Watsen Juergen Schoenwaelder Filename : draft-ietf-netconf-server-model-06.txt Pages : 50 Date : 2015-02-02 Abstract: This draft defines a NETCONF server configuration data model and a RESTCONF server configuration data model. These data models enable configuration of the NETCONF and RESTCONF services themselves, including which transports are supported, what ports the servers listens on, whether call-home is supported, and associated parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-server-model-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-server-model-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 2 11:58: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 BD7661A1A8F for ; Mon, 2 Feb 2015 11:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j3KchAfiRq8P for ; Mon, 2 Feb 2015 11:58:47 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5C61A1A0C for ; Mon, 2 Feb 2015 11:58:46 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.75.20; Mon, 2 Feb 2015 19:58:44 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.196]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.196]) with mapi id 15.01.0075.002; Mon, 2 Feb 2015 19:58:44 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-server-model-06.txt Thread-Index: AQHQPyFehVmOVV4qWEizHJ8Qa1KkTZzdczOA Date: Mon, 2 Feb 2015 19:58:43 +0000 Message-ID: References: <20150202194924.24680.16859.idtracker@ietfa.amsl.com> In-Reply-To: <20150202194924.24680.16859.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.12] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 0475418F50 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(479174004)(377424004)(24454002)(102836002)(110136001)(86362001)(50986999)(76176999)(54356999)(40100003)(15975445007)(230783001)(92566002)(1720100001)(2950100001)(19580405001)(83506001)(2351001)(2501002)(107886001)(122556002)(46102003)(77156002)(62966003)(106116001)(2900100001)(450100001)(66066001)(87936001)(36756003)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <9E5EA6400E8D094583ADA25420FEBDE3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2015 19:58:43.8710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-server-model-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 19:58:49 -0000 The change log for -06 is: o Removed feature statement on the session-options container (issue #21). o Added NACM statements to YANG modules for sensitive nodes (issue #24). o Fixed default RESTCONF server port value to be 443 (issue #26). o Added client-cert-auth subtree to ietf-restconf-server module (issue #27). o Updated draft-ietf-netmod-snmp-cfg reference to RFC 7407 (issue #28). o Added description statements for groupings (issue #29). o Added description for braces to tree diagram section (issue #30). o Renamed feature from "rfc6187" to "ssh-x509-certs" (issue #31). The this point, either all issues are closed or in the "Review" state. Three issues are in the Review state: 18, 24, 27. Note: the change for #18 was made in -05 but was erroneously brought back to the Edit state 3 weeks ago - it should've gone to the Review state, as it is doing now. In either case, there are currently no more pending issues for this draft. Cheers, Kent On 2/2/15, 2:49 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Server and RESTCONF Server >Configuration Models > Authors : Kent Watsen > Juergen Schoenwaelder > Filename : draft-ietf-netconf-server-model-06.txt > Pages : 50 > Date : 2015-02-02 > >Abstract: > This draft defines a NETCONF server configuration data model and a > RESTCONF server configuration data model. These data models enable > configuration of the NETCONF and RESTCONF services themselves, > including which transports are supported, what ports the servers > listens on, whether call-home is supported, and associated > parameters. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-server-model-06 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Feb 3 03:56: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 F18561A00A3 for ; Tue, 3 Feb 2015 03:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS53tDlpOTTb for ; Tue, 3 Feb 2015 03:56:23 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFDF1A0084 for ; Tue, 3 Feb 2015 03:56:22 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t13BuIqK008323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Feb 2015 11:56:18 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 t13Btj0d010275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 12:56:18 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0224.002; Tue, 3 Feb 2015 12:55:57 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Call for Adoption of two new WG Items splitted from RESTCONF Thread-Index: AdA/F6IgNKjf8JhMQPOJlQJ4Uu0cbgAZqemAAAo09lA= Date: Tue, 3 Feb 2015 11:55:56 +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.124] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81960E8E7DEMUMBX005nsnin_" 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: 29339 X-purgate-ID: 151667::1422964578-00007286-79EB5DC8/0/0 Archived-At: Subject: [Netconf] Call for Adoption of two new WG Items splitted from RESTCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 11:56:26 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81960E8E7DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, providing Restconf Collection and YANG library as separate drafts has been = proposed as part of the Restconf issue solving (issues #3 and #13). The iss= ues were in VERIFY state some time without objection. As such we assume alr= eady some agreement for the separation. Restconf Collection and YANG library have been now provided as two separate= drafts: https://tools.ietf.org/html/draft-ietf-netconf-restconf-collection-00 https://tools.ietf.org/html/draft-ietf-netconf-yang-library-00 After checking with our AD Benoit, this is the final WG call for the adopti= on of the two drafts above as WG item documents, with a shorted deadline fo= r 4 business days. If there is no strong objection by February 9, 2015 EOB PT, the co-chairs w= ill work with our AD to update the charter deliverables (as the current cha= rter covers Restconf and there is no additional feature in these drafts, th= e charter text will not be changed). @All: Please upload documents in the future as draft-ietf-netconf only afte= r checking with the co-chairs and the approval of the charter update. Best Regards, Mehmet & Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F81960E8E7DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dear NETCONF WG,

=

= providing Restconf Collection and YANG library as separate drafts has been proposed as part of the Restconf issue solving (issues #3 and #13). T= he issues were in VERIFY state some time without objection. As such we assu= me already some agreement for the separation.

=  =

= Restconf Collection and YANG library have been now provided as two sepa= rate drafts:

= https://tools.ietf.org/html/draft-ietf-netconf-restconf-collection-00

= https://tools.ietf.org/html/draft-ietf-netconf-yang-library-00

=

= After checking with our AD Benoit, this is the final WG call for the adoption of the two drafts above as WG item documents, with a shorted dead= line for 4 business days.

= If there is no strong objection by February 9, 2015 EOB PT, the co-chai= rs will work with our AD to update the charter deliverables (as the current c= harter covers Restconf and there is no additional feature in these drafts, = the charter text will not be changed).

=  

= @All: Please upload documents in the future as draft-ietf-netconf only after checking with the co-chairs and the approval of the charter update.<= o:p>

=

= Best Regards,

= Mehmet & Mahesh

 <= /o:p>

--_000_E4DE949E6CE3E34993A2FF8AE79131F81960E8E7DEMUMBX005nsnin_-- From nobody Tue Feb 3 07:44:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC821A0A85 for ; Tue, 3 Feb 2015 07:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN3L8hAdsEOg for ; Tue, 3 Feb 2015 07:44:18 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E2781A0A6A for ; Tue, 3 Feb 2015 07:44:18 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id w8so34343823qac.13 for ; Tue, 03 Feb 2015 07:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=MLSCId9SogTgwPD4cZbsz2geRnhRY+VZUwX78nnBQw0=; b=Zno7QMsUsZJ3aCSgBXhh/91IGLpQJQZV89e8JYh1a277IGLGBj9xWjhpFYa8/tlz49 mVPD14fNjIKTjgl29cxQoa8B83O+qkG0cEFqg9/4NZsv2NgVWQGrpTQTj4Yny0+95F6j rG6Zfp9opZfJP5GdZVxMHaIKnzt6p6KhL3hdv9vcl9CDjaSE9rY6BE9EHtW0KwyNszmH xtNPlA8r3A7erhcHTZ1y9MrvP7pDlDAW8gjviLprNhtlvgIO0E4Zok8i8NgQbXJHa92S PhXcUPfQcjW6iCFhGVY5z0qvoilFfA52iQAA6atTy20fXsGyLpz1mwjx9r0LwS/eso6v bSnA== X-Received: by 10.140.80.201 with SMTP id c67mr5396634qgd.74.1422978257275; Tue, 03 Feb 2015 07:44:17 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id g7sm10483896qag.26.2015.02.03.07.44.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Feb 2015 07:44:16 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_2829E99A-590B-4328-8C46-BFDC634256B2" Date: Tue, 3 Feb 2015 07:44:14 -0800 Message-Id: To: Netconf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Netconf] Call for agenda items 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, 03 Feb 2015 15:44:19 -0000 --Apple-Mail=_2829E99A-590B-4328-8C46-BFDC634256B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a call for agenda items for IETF 92 in Dallas in March. Please = provide topics that you would like to discuss in the meeting. We will = publish a draft agenda later in February. Cheers. Mahesh & Mehmet --Apple-Mail=_2829E99A-590B-4328-8C46-BFDC634256B2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
This is a call for agenda items for IETF 92 in Dallas in March. Please provide topics that you would like to discuss in the meeting. We will publish a draft agenda later in February.

Cheers.

Mahesh & Mehmet




--Apple-Mail=_2829E99A-590B-4328-8C46-BFDC634256B2-- From nobody Wed Feb 4 03:11:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B531A874D for ; Wed, 4 Feb 2015 03:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 z598dq5kBzCb for ; Wed, 4 Feb 2015 03:11:41 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::738]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AF91A8752 for ; Wed, 4 Feb 2015 03:11:40 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 4 Feb 2015 11:11:17 +0000 Message-ID: <019601d0406b$16414900$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (NSN - DE/Munich)" , References: Date: Wed, 4 Feb 2015 11:09:38 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR03CA0020.eurprd03.prod.outlook.com (25.160.39.158) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) Authentication-Results: nsn.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB063; X-Forefront-PRVS: 04772EA191 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(24454002)(377454003)(15584002)(122386002)(44716002)(62236002)(19580395003)(19580405001)(84392001)(66066001)(50466002)(47776003)(40100003)(81686999)(76176999)(81816999)(50986999)(92566002)(23756003)(86362001)(44736004)(50226001)(107886001)(61296003)(42186005)(46102003)(230783001)(33646002)(1720100001)(77096005)(15975445007)(116806002)(14496001)(62966003)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Feb 2015 11:11:17.5098 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB063 Archived-At: Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 11:11:45 -0000 I think that with the removal of the reference to server model, then the steps in section 7 become hard to follow, almost incomprehensible - they presume an information model which is not specified. I think that Martin's comments revolved around this issue and that it is insufficiently resolved. So I would rewrite section 7, not changing the meaning one iota (well, if I have, then I think the section must be incomprehensible:-) OLD o The server maintains an ordered list of mappings of certificates to NETCONF usernames. The username is derived by considering each list entry in order. The fingerprint member of a list entry determines whether the list entry is a match: 1. If the list entry's fingerprint value matches that of the presented certificate, then consider the list entry as a successful match. 2. If the list entry's fingerprint value matches that of a locally held copy of a trusted CA certificate, and that CA certificate was part of the CA certificate chain to the presented certificate, then consider the list entry as a successful match. o Once a matching list entry has been found, the mapping type property of the list entry is used to determine how the username associated with the certificate should be determined. Possible mapping options are: A. The username is explicitly configured. B. The subjectAltName's rfc822Name is mapped to a username. C. The subjectAltName's dNSName is mapped to a username. D. The subjectAltName's iPAddress is mapped to a username. E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress is mapped to a username. F. The certificate's CommonName is mapped to a username. o If it is impossible to determine a username from the list entry's data combined with the data presented in the certificate, then additional list entries MUST be searched looking for another potential match. Similarily, if the username does not comply to the NETCONF requirements on usernames [RFC6241] (i.e., the username is not representable in XML), then additional list entries MUST be searched looking for another potential match. If there are no further list entries, the TLS session MUST be terminated. NEW o The server maintains an ordered list, with each entry containing a certificate fingerprint, a NETCONF username and, optionally, one or more fields that may appear in the certificate, namely the rfc822Name, dNSName or iPAddress as they appear in the subjectAltName field, or the commonName [X520CommonName?] . The username is derived by considering each list entry in order. If the list entry matches the presented certificate, then further checks are carried out based on the list entry. If these result in an acceptable username, then the search terminates. If the username is not acceptable, then the search continues with the next list entry. If there are no further list entries, the TLS session MUST be terminated. The test for a matching certificate is as follows. 1. If the fingerprint value of the list entry matches the fingerprint of the presented certificate, then consider the list entry as a successful match. 2. If the fingerprint value of the list entry matches that of a locally held copy of a trusted CA certificate, and that CA certificate was part of the CA certificate chain to the presented certificate, then consider the list entry as a successful match. Once a matching list entry has been found, the list entry is considered further. If the username does not comply to the NETCONF requirements on usernames [RFC6241] (i.e., the username is not representable in XML), then the username is not acceptable and list entries MUST be searched looking for another certificate match. A. If the list entry contains just a compliant username, then that username is used. B. If the list entry contains just an rfc822Name which matches that in the matched certificate, then the username from the list entry is used.. C. If the list entry contains just a dNSName which matches that in the matched certificate, then the username from the list entry is used.. D. If the list entry contains just an iPAddress which matches that in the matched certificate, then the username from the list entry is used.. . E. If the list entry contains more than one of rfc822Name, dNSName and iPAddress, and one or more of them match the corresponding fields in the matched certificate, then the username from the list entry is used.. [What happens if e.g. the dNSName matches but the rfc822Name does not? Needs clarifying IMO] F. If the commonName matches that in the matched certificate, then the username from the list entry is used.. G. If none of the steps above yield an acceptable username, then additional list entries MUST be searched looking for a further certificate match. Tom Petch ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: Sent: Friday, January 30, 2015 2:17 PM Subject: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 > Dear NETCONF WG, > > we think the WGLC of the draft-ietf-netconf-rfc5539bis was successful > with useful comments and discussion. Based on the WGLC result Juergen > provided draft-ietf-netconf-rfc5539bis-08. > > See http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08 > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-08.txt > > Please look at v08 of the draft and let the co-chairs know by February 4, > 2015 EOB PT, whether you have any objections to starting the publications > process and asking our AD Benoit Claise to do his review. > > Best Regards, > Mehmet and Mahesh > > > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, January 27, 2015 8:24 AM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: netconf@ietf.org > Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 > > On Mon, Jan 05, 2015 at 08:46:09PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Dear NETCONF Members, > > > > we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. > > > > The document can be found at: > > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 > > > > Please review and send your comments to the WG mailing list by January 19, 2015 EOB PT. > > > > Mehmet and Mahesh, > > I have posted draft-ietf-netconf-rfc5539bis-08 which I believe > addresses the WG last call comments. Please check and if you agree, > please produce a document writeup and move the I-D over to the IESG. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Feb 4 15:13: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 A1AF41A0011 for ; Wed, 4 Feb 2015 15:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stbhhQj6SNU3 for ; Wed, 4 Feb 2015 15:13:22 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0F11A000D for ; Wed, 4 Feb 2015 15:13:22 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id hv19so3140382lab.10 for ; Wed, 04 Feb 2015 15:13:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pjjUsC4ReazpLJU6nTwJnSYJzSqgjk6uY3xqBbo8wno=; b=cqr00IWO3ctZwGOjSphzn/Q2SCtKROodbIQPdJ+KGAiiB+CDKRHvcVUtnDCDKMWK84 Y85qQ7KLWyKr+qvX9RjQGb+GxOSZkudnfnZJzA4VQ45PoMYX06aZtFg7gnzKmeS+y1F5 zEhnbDjwr4z8DZZQAA2iR/ZcGrPG5qWoGgSspvP4B6DcOUKXkccYIChyu9u6FPMFlfGV spOmq0SItrRsw5muheANGg6n6eVoSYupnVaqpLvhEJk4QFgcwCUe1yM5YBGMmUJrPQmZ ussNj1BGgZjq5CUfEeIBqw6udxhRqU0VbuxlVXftBlbcUFTNg+RlSrA07NRJKK+NJwGs lOZA== X-Gm-Message-State: ALoCoQl6RwbmFKI1oCSbvbmYLRNIjQnrIGXRFfNENVcGZYFHmmQwceqaRi1AKsrAwmooUoRDTxUT MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr664817lbv.21.1423091600809; Wed, 04 Feb 2015 15:13:20 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 4 Feb 2015 15:13:20 -0800 (PST) In-Reply-To: <20150202.203357.2240513349527110616.mbj@tail-f.com> References: <20150131043354.17295.24489.idtracker@ietfa.amsl.com> <201502021835.t12IZ2ap027185@idle.juniper.net> <20150202.203357.2240513349527110616.mbj@tail-f.com> Date: Wed, 4 Feb 2015 15:13:20 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-yang-library-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 23:13:25 -0000 On Mon, Feb 2, 2015 at 11:33 AM, Martin Bjorklund wrote: > Phil Shafer wrote: >> internet-drafts@ietf.org writes: >> > Title : YANG Module Library >> > Authors : Andy Bierman >> > Martin Bjorklund >> > Kent Watsen >> > Filename : draft-ietf-netconf-yang-library-00.txt >> >> The concept of "conformace" here is still not compatible with my >> understanding of YANG's import statement. Since importing a statement >> doesn't mean one implements the module, it's not proper to announce >> modules one doesn't implement (viewed here a "conformance false" >> modules) via > > Agreed. > >> so it wouldn't make sense here either. > > Disagree. Unless import-by revision is used everywhere (it is not), > this can be useful (see solution P1b-01 in > draft-bjorklund-yang-conformance-problem-00). There are other ways of > solving this as well (see the draft). > The conformance leaf is compatible with the consensus that the server implements one revision of a module. This leaf would be set to 'true' for the 1 revision that the server would advertise. It is set to 'false' for any other revisions of the smae module that might be present. > > /martin > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Feb 4 20:35: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 B2DE31A1A28 for ; Wed, 4 Feb 2015 20:35:23 -0800 (PST) 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 x-rwPQS7D2mO for ; Wed, 4 Feb 2015 20:35:21 -0800 (PST) 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 E747C1A0373 for ; Wed, 4 Feb 2015 20:35:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSD03990; Thu, 05 Feb 2015 04:35:18 +0000 (GMT) Received: from SZXEML429-HUB.china.huawei.com (10.82.67.184) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Feb 2015 04:35:17 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.141]) by SZXEML429-HUB.china.huawei.com ([10.82.67.184]) with mapi id 14.03.0158.001; Thu, 5 Feb 2015 12:35:13 +0800 From: Rohit R Ranade To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" Thread-Topic: Notification updation RFC 5277 Thread-Index: AdAdmGPAceznqgnXSje9O6PD47W4GwKspEggBix6hTA= Date: Thu, 5 Feb 2015 04:35:13 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A671E1E18@szxeml512-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A671DA5FC@szxeml512-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.144.92] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A671E1E18szxeml512mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 04:35:23 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A671E1E18szxeml512mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Sorry for the late reply. My client has a scenario, where he uses a single session to configure and t= rack notifications. His modules will init at different times and each module want to subscribe = to different events. Since all modules will use same session, just having create-subscription wi= ll not be sufficient. With Regards, Rohit From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com] Sent: 05 January, 2015 00:30 To: Rohit R Ranade; netconf@ietf.org Subject: RE: Notification updation RFC 5277 Dear Rohit, can you elaborate in which scenario you need to modify a notification subsc= ription? Regards, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Rohit R Ra= nade Sent: Monday, December 22, 2014 4:36 AM To: netconf@ietf.org Subject: [Netconf] Notification updation RFC 5277 Hello, RFC 5277 clearly states that subscriptions cannot be updated. Is there some= reason for it ? I have a scenario, where subscriptions can get added and d= eleted. Is there some mechanism to update subscription ? With Regards, Rohit --_000_991B70D8B4112A4699D5C00DDBBF878A671E1E18szxeml512mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

 

Sorry for the late rep= ly.

My client has a scenar= io, where he uses a single session to configure and track notifications.

His modules will init = at different times and each module want to subscribe to different events.

Since all modules will= use same session, just having create-subscription will not be sufficient.<= o:p>

 

With Regards,

Rohit

 

 

From: Ersue, M= ehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]
Sent: 05 January, 2015 00:30
To: Rohit R Ranade; netconf@ietf.org
Subject: RE: Notification updation RFC 5277

 

Dear Rohit,

 

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

 

Regards,
Mehmet

 

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

 

Hello,

 

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

Is there some mechanism to update subscription ?

 

With Regards,

Rohit

--_000_991B70D8B4112A4699D5C00DDBBF878A671E1E18szxeml512mbschi_-- From nobody Thu Feb 5 03:52: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 3E9DE1A8708 for ; Thu, 5 Feb 2015 03:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 nQ1EOd1mvcOV for ; Thu, 5 Feb 2015 03:52:24 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5590E1A8704 for ; Thu, 5 Feb 2015 03:52:24 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) with Microsoft SMTP Server (TLS) id 15.1.81.19; Thu, 5 Feb 2015 10:49:30 +0000 Message-ID: <012d01d04131$348cf3c0$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (NSN - DE/Munich)" References: Date: Thu, 5 Feb 2015 10:47:52 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR03CA0031.eurprd03.prod.outlook.com (25.160.39.169) To DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) Authentication-Results: nsn.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB058; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB058; X-Forefront-PRVS: 0478C23FE0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(1456003)(47776003)(23756003)(61296003)(50986999)(44716002)(62236002)(50226001)(44736004)(33646002)(40100003)(93886004)(87976001)(66066001)(116806002)(558084003)(81686999)(221733001)(76176999)(122386002)(110136001)(229853001)(50466002)(42186005)(62966003)(46102003)(92566002)(86362001)(77096005)(77156002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB058; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB058; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Feb 2015 10:49:30.0317 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB058 Archived-At: Cc: Netconf Subject: [Netconf] Virtual interim 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, 05 Feb 2015 11:52:26 -0000 A post to the list on 8Jan2015 has a subject of Minutes from the NETCONF Interim Meeting on January 5th, 2015 but the attached document says Minutes of the virtual interim meeting on December 15,2014 1700-1900 UTC Can I assume that this really relates to the January 5th meeting? Tom Petch From nobody Thu Feb 5 04:57: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 3400E1A00F8 for ; Thu, 5 Feb 2015 04:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_45=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 tQfJ6oRzfnUq for ; Thu, 5 Feb 2015 04:57:26 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA9D1A0091 for ; Thu, 5 Feb 2015 04:57:25 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t15CvM80015874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Feb 2015 12:57:22 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 t15CvI1H024321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 13:57:21 +0100 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, 5 Feb 2015 13:57:18 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0224.002; Thu, 5 Feb 2015 13:57:18 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext t.petch" Thread-Topic: Virtual interim Thread-Index: AQHQQTFtjNnbjbTHdk66t9Ddib+ClZziA9Mg Date: Thu, 5 Feb 2015 12:57:18 +0000 Message-ID: References: <012d01d04131$348cf3c0$4001a8c0@gateway.2wire.net> In-Reply-To: <012d01d04131$348cf3c0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 590 X-purgate-ID: 151667::1423141042-000067C4-A3C9941B/0/0 Archived-At: Cc: Netconf Subject: Re: [Netconf] Virtual interim 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, 05 Feb 2015 12:57:28 -0000 The date in the attached file is obviously a copy&paste error. Mehmet=20 -----Original Message----- From: ext t.petch [mailto:ietfc@btconnect.com]=20 Sent: Thursday, February 05, 2015 11:48 AM To: Ersue, Mehmet (NSN - DE/Munich) Cc: Netconf Subject: Virtual interim A post to the list on 8Jan2015 has a subject of Minutes from the NETCONF Interim Meeting on January 5th, 2015 but the attached document says Minutes of the virtual interim meeting on December 15,2014 1700-1900 UTC Can I assume that this really relates to the January 5th meeting? Tom Petch From nobody Thu Feb 5 05:23:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240E91A879A; Thu, 5 Feb 2015 05:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EomWfvpMzlN3; Thu, 5 Feb 2015 05:22:54 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399381A87AA; Thu, 5 Feb 2015 05:22:47 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t15DMijx020257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Feb 2015 13:22:45 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 t15DMhjJ014187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 14:22:44 +0100 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; Thu, 5 Feb 2015 14:22:43 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0224.002; Thu, 5 Feb 2015 14:22:43 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available Thread-Index: AdA9Z1V9LrIizW9/SFC3DbYz1F9geAD3GWuA Date: Thu, 5 Feb 2015 13:22:43 +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.119] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_" 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: 39423 X-purgate-ID: 151667::1423142565-000067C4-BF5EA218/0/0 Archived-At: Cc: "i2rs@ietf.org" , "6lo@ietf.org" <6lo@ietf.org>, "ops-ads@tools.ietf.org" , "app-ads@tools.ietf.org" , "core@ietf.org" , "rtg-ads@tools.ietf.org" , "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 13:23:07 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, we hereby issue a WG Last Call for 3 weeks for the drafts below: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Please review and send your comments to the NETCONF WG mailing list by Febr= uary 26, 2015 EOB PT. The related draft-ietf-netconf-yang-library will follow with LC as soon as = the remaining two issues are solved (see http://tools.ietf.org/html/draft-ietf-netconf-yang-library). RESTCONF documents are planned to publish as standard track documents. As RESTCONF is a major protocol we expect a detailed and thorough review wi= thin NETCONF WG but also by the related WGs before publishing. Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs wil= l be informed as well as Core, I2rs, 6lo, and 6tisch WGs are invited to rev= iew. Please state explicitly that you have read/reviewed and whether you support= the publication. Please indicate also if you plan to implement or have already implementatio= n experience with RESTCONF. Thank you, Mehmet and Mahesh From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Saturday, January 31, 2015 4:05 PM To: netconf@ietf.org Subject: [Netconf] Restconf-04 and YANG-Patch-03 drafts available All, 1 YANG patch and 9 Restconf issues have been solved and provided in the dra= fts below. These issues have been set to the status Review (https://github.com/netconf= -wg/restconf/issues). Please check and comment on the drafts below before we go to WGLC soon: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dear NETCONF WG,

=

= we hereby issue a WG Last Call for 3 weeks for the drafts below:

=  

https://tools.ietf.org/html/draft-ietf-netconf-restconf-04

https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-= 03

=  

= Please review and send your comments to the NETC= ONF WG mailing list by February 26, 2015 EOB PT.

= The related draft-ietf-netconf-yang-library will follow with LC as soon as the remaining two issues are solved <= /span>

= (see http://tools.ietf.org/html/draft-ietf-netco= nf-yang-library).

=

= RESTCONF documents are planned to publish as standard track documents.

= As RESTCONF is a major protocol we expect a deta= iled and thorough review within NETCONF WG but also by the related WGs before p= ublishing.

= Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs will be informed as well as Core, I2rs, 6lo, and= 6tisch WGs are invited to review.

=

= Please state explicitly that you have read/revie= wed and whether you support the publication.

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

=  

= Thank you,

= Mehmet and Mahesh

=  

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Saturday, January 31, = 2015 4:05 PM
To: netconf@ietf.org
Subject: [Netconf] Restconf-= 04 and YANG-Patch-03 drafts available

 

All,

 

1 YANG patch and 9 Restconf = issues have been solved and provided in the drafts below.

These issues have been set t= o the status Review (https://github.com/netconf-wg/restconf/issues).

 

Please check and comment on = the drafts below before we go to WGLC soon:

=  

= Regards,
Mehmet

=  

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_-- From nobody Thu Feb 5 05:32:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB131A8874 for ; Thu, 5 Feb 2015 05:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZW3fQ3EqOTj for ; Thu, 5 Feb 2015 05:32:39 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487521A1AA5 for ; Thu, 5 Feb 2015 05:32:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 14B2917F5; Thu, 5 Feb 2015 14:32:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Hy5z9MaO3hax; Thu, 5 Feb 2015 14:32:16 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Feb 2015 14:32:36 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B85620036; Thu, 5 Feb 2015 14:32:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PrL-0TA3xR6M; Thu, 5 Feb 2015 14:24:31 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0699920035; Thu, 5 Feb 2015 14:32:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 288293190CDA; Thu, 5 Feb 2015 14:32:35 +0100 (CET) Date: Thu, 5 Feb 2015 14:32:35 +0100 From: Juergen Schoenwaelder To: Rohit R Ranade Message-ID: <20150205133235.GC39798@elstar.local> Mail-Followup-To: Rohit R Ranade , "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A671DA5FC@szxeml512-mbs.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A671E1E18@szxeml512-mbs.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671E1E18@szxeml512-mbs.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 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, 05 Feb 2015 13:32:40 -0000 Hi, RFC 5277 has its limits... You can either try to delay subscription until all modules have finished their initialization or if that is not feasible, you will have to restart the session whenever the subscription needs to change. /js On Thu, Feb 05, 2015 at 04:35:13AM +0000, Rohit R Ranade wrote: > Hi, > > Sorry for the late reply. > My client has a scenario, where he uses a single session to configure and track notifications. > His modules will init at different times and each module want to subscribe to different events. > Since all modules will use same session, just having create-subscription will not be sufficient. > > With Regards, > Rohit > > > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com] > Sent: 05 January, 2015 00:30 > To: Rohit R Ranade; netconf@ietf.org > Subject: RE: Notification updation RFC 5277 > > Dear Rohit, > > can you elaborate in which scenario you need to modify a notification subscription? > > Regards, > Mehmet > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Rohit R Ranade > Sent: Monday, December 22, 2014 4:36 AM > To: netconf@ietf.org > Subject: [Netconf] Notification updation RFC 5277 > > Hello, > > RFC 5277 clearly states that subscriptions cannot be updated. Is there some reason for it ? I have a scenario, where subscriptions can get added and deleted. > Is there some mechanism to update subscription ? > > With Regards, > Rohit > _______________________________________________ > 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 Feb 5 07:45: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 5B37C1A8889 for ; Thu, 5 Feb 2015 07:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fXPBwG5XoOd for ; Thu, 5 Feb 2015 07:45:07 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E119F1A88D3 for ; Thu, 5 Feb 2015 07:45:06 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.75.20; Thu, 5 Feb 2015 15:44:43 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.47]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.47]) with mapi id 15.01.0075.002; Thu, 5 Feb 2015 15:44:43 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Rohit R Ranade" Thread-Topic: [Netconf] Notification updation RFC 5277 Thread-Index: AdAdmGPAceznqgnXSje9O6PD47W4GwKspEggBix6hTAAEtUegP//0RUA Date: Thu, 5 Feb 2015 15:44:42 +0000 Message-ID: References: <991B70D8B4112A4699D5C00DDBBF878A671DA5FC@szxeml512-mbs.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A671E1E18@szxeml512-mbs.china.huawei.com> <20150205133235.GC39798@elstar.local> In-Reply-To: <20150205133235.GC39798@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.14] authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(66066001)(46102003)(2656002)(87936001)(86362001)(77156002)(62966003)(50986999)(102836002)(2900100001)(2950100001)(54356999)(92566002)(76176999)(83506001)(122556002)(99286002)(40100003)(36756003)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2015 15:44:42.6279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 15:45:10 -0000 >RFC 5277 has its limits... Indeed >You can either try to delay subscription until all modules have >finished their initialization or if that is not feasible, you will >have to restart the session whenever the subscription needs to change. Some applications set up a secondary subscription and then drop the first subscription...removing duplicate events received during the transition. It's nasty business, much cleaner would be an ability to modify the existing subscription. Thanks, Kent From nobody Thu Feb 5 07:53: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 C052D1A88E2 for ; Thu, 5 Feb 2015 07:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NimD6XNqukgm for ; Thu, 5 Feb 2015 07:53:32 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD77B1A88D3 for ; Thu, 5 Feb 2015 07:53:32 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 81FA21CEC; Thu, 5 Feb 2015 16:53:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dBnUirk2ibRp; Thu, 5 Feb 2015 16:53:10 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Feb 2015 16:53:31 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE18020036; Thu, 5 Feb 2015 16:53:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AnAVcVQdRjjU; Thu, 5 Feb 2015 16:53:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F416020035; Thu, 5 Feb 2015 16:53:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 20B193192597; Thu, 5 Feb 2015 16:53:30 +0100 (CET) Date: Thu, 5 Feb 2015 16:53:30 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150205155330.GB43534@elstar.local> Mail-Followup-To: Kent Watsen , Rohit R Ranade , "netconf@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A671DA5FC@szxeml512-mbs.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A671E1E18@szxeml512-mbs.china.huawei.com> <20150205133235.GC39798@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Rohit R Ranade , "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 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, 05 Feb 2015 15:53:34 -0000 On Thu, Feb 05, 2015 at 03:44:42PM +0000, Kent Watsen wrote: > > > Some applications set up a secondary subscription and then drop the first > subscription...removing duplicate events received during the transition. > It's nasty business, much cleaner would be an ability to modify the > existing subscription. > Not with RFC 5277 - there is no delete-subscription in RFC 5277. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 5 08:30: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 7C1121A88CF for ; Thu, 5 Feb 2015 08:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTIyOWRZ3dCE for ; Thu, 5 Feb 2015 08:30:26 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE18A1A8761 for ; Thu, 5 Feb 2015 08:30:25 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t15GUNwW003504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Feb 2015 16:30:24 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 t15GUNBG021998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Feb 2015 17:30:23 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 5 Feb 2015 17:30:23 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0224.002; Thu, 5 Feb 2015 17:30:23 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: call-home-04 and server-model-06 available - All Open issues closed Thread-Index: AQHQQWEJCP9pL8UlGkylb/KFjM668A== Date: Thu, 5 Feb 2015 16:30:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8196121FADEMUMBX005nsnin_" 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: 28557 X-purgate-ID: 151667::1423153824-000067C4-1BD71BC0/0/0 Archived-At: Subject: [Netconf] call-home-04 and server-model-06 available - All Open issues closed 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, 05 Feb 2015 16:30:29 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8196121FADEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, all call-home issues have been solved and there are 3 issues for server-mod= el draft in REVIEW state. See https://github.com/netconf-wg/call-home/issues?q=3Dis%3Aissue+is%3Aclos= ed and https://github.com/netconf-wg/server-model/issues. Please check the provided solutions in the updated drafts and comment befor= e we go to WGLC after the end of Restconf LC. https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F8196121FADEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= All,

=

= all call-home issues have been solved and there are 3 issues for server-model draft in REVIEW state.

= See https://github.com/netconf-wg/call-home/issues?q=3Dis%3Aissue+is%3Aclos= ed and

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

=  

= Please check the provided solutions in the updat= ed drafts and comment before we go to WGLC after the end of Restconf LC.=

=  

= https://tools.ietf.org/html/draft-ietf-netconf-call= -home-04  

= https://tools.ietf.org/html/draft-ietf-netconf-s= erver-model-06  

=  

= Regards,

= Mehmet

=  

--_000_E4DE949E6CE3E34993A2FF8AE79131F8196121FADEMUMBX005nsnin_-- From nobody Thu Feb 5 09:06:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2361A89A1 for ; Thu, 5 Feb 2015 09:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZQ98uSAZoWv for ; Thu, 5 Feb 2015 09:06:31 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F65D1A064C for ; Thu, 5 Feb 2015 09:06:31 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.75.20; Thu, 5 Feb 2015 17:06:29 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.47]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.47]) with mapi id 15.01.0075.002; Thu, 5 Feb 2015 17:06:29 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] Notification updation RFC 5277 Thread-Index: AdAdmGPAceznqgnXSje9O6PD47W4GwKspEggBix6hTAAEtUegP//0RUAgABWSgD//8CQgA== Date: Thu, 5 Feb 2015 17:06:29 +0000 Message-ID: References: <991B70D8B4112A4699D5C00DDBBF878A671DA5FC@szxeml512-mbs.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A671E1E18@szxeml512-mbs.china.huawei.com> <20150205133235.GC39798@elstar.local> <20150205155330.GB43534@elstar.local> In-Reply-To: <20150205155330.GB43534@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.10] authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(51704005)(377454003)(46102003)(50986999)(2900100001)(54356999)(76176999)(102836002)(2950100001)(122556002)(36756003)(40100003)(77156002)(62966003)(66066001)(83506001)(93886004)(110136001)(86362001)(87936001)(92566002)(99286002)(2656002)(19580395003)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <5B1E9B6CA4FB7D44A80A8F168D1C173D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2015 17:06:29.3405 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Cc: Rohit R Ranade , "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 17:06:33 -0000 On 2/5/15, 10:53 AM, "Juergen Schoenwaelder" wrote: >On Thu, Feb 05, 2015 at 03:44:42PM +0000, Kent Watsen wrote: >>=20 >>=20 >> Some applications set up a secondary subscription and then drop the >>first >> subscription...removing duplicate events received during the transition. >> It's nasty business, much cleaner would be an ability to modify the >> existing subscription. >> > >Not with RFC 5277 - there is no delete-subscription in RFC 5277. Poor man's delete: drop the underlying NETCONF session. The assumption is that there is a dedicated NETCONF session for each subscription (no interleaving). Using SSH channels, this can be a fairly cheap operation, reusing the same underlying SSH connection. Kent From nobody Thu Feb 5 09:07:12 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11591A00CA for ; Thu, 5 Feb 2015 09:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m44Yt28J6Mkk for ; Thu, 5 Feb 2015 09:07:06 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC421A1A67 for ; Thu, 5 Feb 2015 09:07:00 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id b6so9402440lbj.11 for ; Thu, 05 Feb 2015 09:06:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ZbDIhkG7msD6rfcWydBc7rRUvCRuGdzNeujCZmejZcI=; b=ZodlnyVQwNskCVUmt2qdgemnHSiG69Xv+vGgzeLkcgIf9A4lsF6blBbfWdyHyxGqE0 WyiKweJLb8nqMipnWoH3MS5UP8JvfVCvNNQ2QiRWrX8uhCcgCcA0Jlgc3sHB2wKRPE5r ppGdbUDkmqAOsw2rMWvHq35c7r/ZV4cr/8WazmXrTC/V+jKsRy60zz/e+OZMi8e3Z3RV RQ9f2vNptyluBDWWdHHHMo6SeoX2AkoWh4izROY3ez/KlWC9Jq4IJAURUhV96pNRukqj IwYJrGVXWBIDjqdAWVIFf0+VGZyLvQvuNcbRINCmfzVmMmrKZp7ytZTbCUwhlVFJHhNK iaKg== X-Gm-Message-State: ALoCoQlIVT/Vc0t/me+7p+mvhKIS9iir44truFcV+KjDQGUE7iGqPVy16yRRHBFk+sT2/jNmVujV MIME-Version: 1.0 X-Received: by 10.152.5.101 with SMTP id r5mr4856099lar.33.1423156019264; Thu, 05 Feb 2015 09:06:59 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 09:06:59 -0800 (PST) Date: Thu, 5 Feb 2015 09:06:59 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] =?utf-8?q?Library_=231=3A_should_=E2=80=98conformance?= =?utf-8?q?=E2=80=99_leaf_be_removed=3F?= 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, 05 Feb 2015 17:07:12 -0000 Hi, The following issue has been added to the github tracker: https://github.com/netconf-wg/yang-library/issues/1 The 'conformance' leaf indicates (true/false) if the server claims conformance to the specified YANG module. Is this leaf OK or should it be removed to allow a different module to define conformance information? Andy From nobody Thu Feb 5 09:08:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C0C1A00CA for ; Thu, 5 Feb 2015 09:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SVbSGToQx2O for ; Thu, 5 Feb 2015 09:08:47 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192E31A87ED for ; Thu, 5 Feb 2015 09:08:47 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id l4so9407730lbv.13 for ; Thu, 05 Feb 2015 09:08:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=MhBjKxvDwafqbWbXNatZeO+j2VUksLJD2W/uT1F6nEY=; b=DTSLVPIzWI/Cb8DBVO4N6iEf+PlXWzL30NfSstJ+IwM19eNoCuOJr6Ui0KIvRGkK4x bN4OPoJIhRWjT/notZjiXZHEKmRJKJHAj32R53a+FJTV8Es0GkB7AzRsjgOv04zFfpbs 35srwo6sUypxOcvGob0ZHFvyLz5lpLnRhyGbb+i4moSs0/VqYqJqQOw5WxVmqBohO3PK QG7F/IvcUMpyu9ijxzuNVBm3z7E1Co1LD/kpFiqYFTFQlehPDrRMpvaY/1P/boA2AdU6 iYNXdhkAU4216eCXuiLAXA/IlxCrp/czTkzSR2Pcxl1wNqLtH4P16z86qqf9rbPKmauG 7wJQ== X-Gm-Message-State: ALoCoQn5nf8eJ7lLs9q3runi+ysvee5RlZgv2OajwkyQqq0EiaF1+fNicz5QPHX3Ct/UmHWFCoOU MIME-Version: 1.0 X-Received: by 10.152.22.39 with SMTP id a7mr1378446laf.119.1423156125634; Thu, 05 Feb 2015 09:08:45 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 09:08:45 -0800 (PST) Date: Thu, 5 Feb 2015 09:08:45 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] Library #2: should multi-protocol information be added? 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, 05 Feb 2015 17:08:49 -0000 Hi, The following issue has been added to the github tracker: https://github.com/netconf-wg/yang-library/issues/2 Should information be added to identify which protocols use each module or should each protocol define their own augmentations? Andy From nobody Thu Feb 5 09:11:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8521A064C for ; Thu, 5 Feb 2015 09:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNqDytp5SC6I for ; Thu, 5 Feb 2015 09:11:35 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3FD1A00CA for ; Thu, 5 Feb 2015 09:11:35 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id f15so9474572lbj.5 for ; Thu, 05 Feb 2015 09:11:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=+/nEp4DQfwA2MlrcK1ulHd2NooSm8ei71cPNZeSrvgk=; b=Ucw+zxakwqUslJfFM8TQSn0oLlAGmI5X5eQ3K/pxLskvqGSiO2fJ6Nx4Ol6CvyGwV9 rzHOgbA8xepc/OvtG6s/f0SnraYX7WW8NDlL4zjF8pTQu5RJuC0oEU9r21KcnlUnbtJ0 O3AjMNq1+SOlrmz5OQ23M97EAf5rYopk1f1SLQNRli0cR+1tzwjCAcdVIrTTgSaUYnaG Bhg3noZ3lNfsGH+DBZMskzCCJ9ErGCBBI4XnhF5W8iAjw0XI0Eet91r1ylHIt0qLdvJA NmVZxyuX2xCi8Vcf8E96feXYy+k5AJV6y11LavXczo7t4uDxIkANYUDbQPlxx8msWamA JNHQ== X-Gm-Message-State: ALoCoQktT2HWEZ19FMjZ65RXZEL3xNaFMlu0ueMJBhNgZqIruUooJbe6mVZyouicPcdvSZXL0EXE MIME-Version: 1.0 X-Received: by 10.112.142.168 with SMTP id rx8mr537387lbb.37.1423156293654; Thu, 05 Feb 2015 09:11:33 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 09:11:33 -0800 (PST) Date: Thu, 5 Feb 2015 09:11:33 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] Library #3: relationship to ietf-netconf-monitoring 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, 05 Feb 2015 17:11:36 -0000 Hi, The following issue has been added to the github tracker: https://github.com/netconf-wg/yang-library/issues/3 A section will be added on the relationship to the existing NETCONF monitoring module. Need to determine consensus on relationship to RFC 6020. A) should the 'schema' list be deprecated and the 'modules' container be implemented or should both data structures be implemented? Recommend: keep both because 'schema' supports more than YANG. B1) should the 'get-schema' RPC support modules and submodules from the YANG library? B2) should the server support the 'schema' leaf (URI) and also support the 'get-schema' RPC? B3) should the 'schema' leaf indicate that 'get-schema' RPC can be used for retrieval? B4) are multiple 'schema' URIs needed? (e.g. like leaf-list 'location') B5) Does YIN format retrieval need to be supported or just YANG format? Andy From nobody Thu Feb 5 09:15: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 039D51A07BD for ; Thu, 5 Feb 2015 09:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmfF0K5uZAqC for ; Thu, 5 Feb 2015 09:15:15 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F177F1A0404 for ; Thu, 5 Feb 2015 09:15:14 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C2D5E13A3; Thu, 5 Feb 2015 18:15:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OFtt-VpIaYe6; Thu, 5 Feb 2015 18:14:52 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Feb 2015 18:15:13 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC76120036; Thu, 5 Feb 2015 18:15:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VzkBR2ASMKxm; Thu, 5 Feb 2015 18:15:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB6BE20035; Thu, 5 Feb 2015 18:15:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E9A9C319345E; Thu, 5 Feb 2015 18:15:10 +0100 (CET) Date: Thu, 5 Feb 2015 18:15:10 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150205171510.GC45218@elstar.local> Mail-Followup-To: Kent Watsen , Rohit R Ranade , "netconf@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A671DA5FC@szxeml512-mbs.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A671E1E18@szxeml512-mbs.china.huawei.com> <20150205133235.GC39798@elstar.local> <20150205155330.GB43534@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Rohit R Ranade , "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 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, 05 Feb 2015 17:15:17 -0000 On Thu, Feb 05, 2015 at 05:06:29PM +0000, Kent Watsen wrote: > > Poor man's delete: drop the underlying NETCONF session. The assumption is > that there is a dedicated NETCONF session for each subscription (no > interleaving). Using SSH channels, this can be a fairly cheap operation, > reusing the same underlying SSH connection. > Yes, SSH channels are reasonably cheap. With TLS, well, you better have session resumption working. I understand that #interleave is optional and hence having delete-subscription would not generally work (nor would modify-subscription). Well, lets see where we end up with the pub/sub discussions underway... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 5 09:19:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0911A0451 for ; Thu, 5 Feb 2015 09:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrpD8KS7-SVb for ; Thu, 5 Feb 2015 09:19:38 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5EC1A0404 for ; Thu, 5 Feb 2015 09:19:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1E1E01D50; Thu, 5 Feb 2015 18:19:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3hJZ_v-K4sSz; Thu, 5 Feb 2015 18:19:15 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Feb 2015 18:19:36 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 496C820038; Thu, 5 Feb 2015 18:19:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6hbX5JPXFr3X; Thu, 5 Feb 2015 18:19:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 379BB20035; Thu, 5 Feb 2015 18:19:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 56FE33193552; Thu, 5 Feb 2015 18:19:35 +0100 (CET) Date: Thu, 5 Feb 2015 18:19:35 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150205171935.GD45218@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] Library #2: should multi-protocol information be added? 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, 05 Feb 2015 17:19:39 -0000 On Thu, Feb 05, 2015 at 09:08:45AM -0800, Andy Bierman wrote: > Hi, > > The following issue has been added to the github tracker: > > https://github.com/netconf-wg/yang-library/issues/2 > > Should information be added to identify which protocols use each module or > should each protocol define their own augmentations? > Are you saying we envision servers supporting both NETCONF and RESTCONF that expose different module sets over NETCONF and RESTCONF? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 5 09:31:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962231A19E4 for ; Thu, 5 Feb 2015 09:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g6EpYv82N6T for ; Thu, 5 Feb 2015 09:31:38 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08FA1A0469 for ; Thu, 5 Feb 2015 09:31:37 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id n10so5408496lbv.6 for ; Thu, 05 Feb 2015 09:31:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=XDx5mB+PFmwXbzif6lItKprOs2R27V8PhKd6sYyFAXk=; b=j/bPCtmR0dtGwp0TpsfJaXcNGN3EOfkzYQSRejs/UNY7Wv/ZbNVA2S3Q5lDa6mjmgX Q3fGTD97abOqcTLQ1CaUCESrm9Fk3OanQ5prLhOoaPpZF0qmrUJiBO3Aezn9b1jNhOwy 1ItuBd0Q0qXzwJk4LKiIQIogTH2VhiYc99jjb8Yc4NzkQu1XzStgQN7nX9sdOtp6cKFN Eu+JHpwGmAwBmUvRo+gtY6ZvxKNXm76/++s79n1yQxlrEXkZnqzTy0WKsjaK2ZUSdOZO rcFC3TvSIIbeF0BjBz6S/KKLj0pG23GnxUeKBA+Nf2G/FE/ULvkfFZJ2oOKcHjO1h2bn ITDw== X-Gm-Message-State: ALoCoQlZv9yU6idip+dpwc1/B8FcGdoiz57skPc0eUbXC0f3phD0Vgq617flK2kLQfY47e1OjwWf MIME-Version: 1.0 X-Received: by 10.112.137.196 with SMTP id qk4mr5016048lbb.33.1423157496048; Thu, 05 Feb 2015 09:31:36 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 09:31:35 -0800 (PST) In-Reply-To: <20150205171935.GD45218@elstar.local> References: <20150205171935.GD45218@elstar.local> Date: Thu, 5 Feb 2015 09:31:35 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] Library #2: should multi-protocol information be added? 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, 05 Feb 2015 17:31:39 -0000 On Thu, Feb 5, 2015 at 9:19 AM, Juergen Schoenwaelder wrote: > On Thu, Feb 05, 2015 at 09:08:45AM -0800, Andy Bierman wrote: >> Hi, >> >> The following issue has been added to the github tracker: >> >> https://github.com/netconf-wg/yang-library/issues/2 >> >> Should information be added to identify which protocols use each module or >> should each protocol define their own augmentations? >> > > Are you saying we envision servers supporting both NETCONF and > RESTCONF that expose different module sets over NETCONF and RESTCONF? > It is already happening. Not all RESTCONF servers are going to support the ietf-netconf RPCs (as operation resources). Martin and I agree that this does not really work for operations that assume NETCONF sessions are being used. Perhaps I2RS modules will not be intended for NETCONF or RESTCONF, but only a new I2RS protocol? There are also the modules like ietf-restconf that only have extensions visible just so they will be invisible to NETCONF. This sort of clumsy multi-protocol support is unsustainable. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Thu Feb 5 09:42: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 B9D831A0469 for ; Thu, 5 Feb 2015 09:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APImP8dHwTBy for ; Thu, 5 Feb 2015 09:42:35 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E877C1A0377 for ; Thu, 5 Feb 2015 09:42:34 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id u14so9746796lbd.2 for ; Thu, 05 Feb 2015 09:42:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=beDFPD2eOsWj0Ali4g6YloudCn8zV0RWEKTgeQx/cTo=; b=iFKO0tLdhTobGCINLk6q7SQE0dbdSfp6O8wuNlbeBn+WJgNaH/AfRXjOHVUxQAP7uM aMgWKb2aXMdItWh3u1EaGKa4yuYoo+3OScCUULboe5uC3aM6fDKiA2smY2UAmP5d/SQy qUzp3QMLyj0OKUG1k1zzUzcHU+DkZ0p6S5xHULtsFWm3OiG6vgxNK2OXmHsUT8jhKIBz fidY+3wb+npn+zG2ecjS/D89hflCqSEztzIyvd4PmmcrQebwHq12AGZSNSSrtdrwPRvd IIegQBXj4y8Px+e/Xt17/16j6ynex4QOlH2K7pOC+8l7NHdNHNOMXfL8lSZa7srrhuN8 hsMw== X-Gm-Message-State: ALoCoQlco2amBtW5eolXgSvMdurzvS6O2LkSbApMrsEXWkYskCQjc9FkU8j+eHqPBZWR5hSpV8hG MIME-Version: 1.0 X-Received: by 10.112.142.168 with SMTP id rx8mr714667lbb.37.1423158153416; Thu, 05 Feb 2015 09:42:33 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 09:42:33 -0800 (PST) In-Reply-To: <20150205171510.GC45218@elstar.local> References: <991B70D8B4112A4699D5C00DDBBF878A671DA5FC@szxeml512-mbs.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A671E1E18@szxeml512-mbs.china.huawei.com> <20150205133235.GC39798@elstar.local> <20150205155330.GB43534@elstar.local> <20150205171510.GC45218@elstar.local> Date: Thu, 5 Feb 2015 09:42:33 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Kent Watsen , Rohit R Ranade , "netconf@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 17:42:36 -0000 On Thu, Feb 5, 2015 at 9:15 AM, Juergen Schoenwaelder wrote: > On Thu, Feb 05, 2015 at 05:06:29PM +0000, Kent Watsen wrote: >> >> Poor man's delete: drop the underlying NETCONF session. The assumption is >> that there is a dedicated NETCONF session for each subscription (no >> interleaving). Using SSH channels, this can be a fairly cheap operation, >> reusing the same underlying SSH connection. >> > > Yes, SSH channels are reasonably cheap. With TLS, well, you better > have session resumption working. I understand that #interleave is > optional and hence having delete-subscription would not generally > work (nor would modify-subscription). Well, lets see where we end > up with the pub/sub discussions underway... > Oh good, I can dust off my list of NETCONF notification gripes ;-) 1) a single replay buffer for all NETCONF events can be over-run. A standard solution would be useful, such as source-filtering or rate-limiting event generation, or standardized priority for dropping events, or multiple standard streams. 2) The current filter mechanism is just awful for describing a pub/sub model. New, simple, less error-prone mechanisms to convey the pub capabilities and the sub requirements are needed. There should be a way to validate subscriptions to make sure they are configured correctly. This is not possible with a generic subtree or XPath filter. 3) the subscription requirements should be configurable to reduce setup complexity and allow re-configuration on-the-fly. RPC-based mechanisms may need to be replaced or enhanced. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Feb 5 10:33: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 9A1211A1A7D for ; Thu, 5 Feb 2015 10:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_nbZz8bIU57 for ; Thu, 5 Feb 2015 10:33:21 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44431A8937 for ; Thu, 5 Feb 2015 10:33:14 -0800 (PST) Received: from CO2PR05CA050.namprd05.prod.outlook.com (10.141.241.178) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.1.81.19; Thu, 5 Feb 2015 18:33:12 +0000 Received: from BN1AFFO11FD032.protection.gbl (2a01:111:f400:7c10::175) by CO2PR05CA050.outlook.office365.com (2a01:111:e400:1429::50) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Thu, 5 Feb 2015 18:33:13 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1AFFO11FD032.mail.protection.outlook.com (10.58.52.186) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Thu, 5 Feb 2015 18:33:11 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Feb 2015 10:32:16 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t15IWDW70091; Thu, 5 Feb 2015 10:32:13 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t15IVw5U056876; Thu, 5 Feb 2015 13:31:59 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502051831.t15IVw5U056876@idle.juniper.net> To: Kent Watsen In-Reply-To: Date: Thu, 5 Feb 2015 13:31:58 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(76506005)(53416004)(2950100001)(86362001)(105596002)(46102003)(106466001)(110136001)(47776003)(92566002)(50466002)(62966003)(54356999)(77096005)(6806004)(48376002)(87936001)(77156002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB444; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CO1PR05MB444; X-Forefront-PRVS: 0478C23FE0 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Feb 2015 18:33:11.6061 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB444 Archived-At: Cc: Rohit R Ranade , "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 18:33:24 -0000 Kent Watsen writes: >>Not with RFC 5277 - there is no delete-subscription in RFC 5277. >Poor man's delete: drop the underlying NETCONF session. ;^) >The assumption is >that there is a dedicated NETCONF session for each subscription (no >interleaving). Using SSH channels, this can be a fairly cheap operation, >reusing the same underlying SSH connection. If we could have made that assumption, the notification mechanism would have been oh-so easy. Instead we designed for interleaving notifications and s. I thing it's too late to start requiring that assumption (unless we want to redesign notifications (which would be a great idea (except for my previous comments re: stability and "done"-ness))). Thanks, Phil From nobody Thu Feb 5 11:11:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6141A6F7A for ; Thu, 5 Feb 2015 11:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWzeTuev5Kfj for ; Thu, 5 Feb 2015 11:11:27 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116FC1A8A07 for ; Thu, 5 Feb 2015 11:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1545; q=dns/txt; s=iport; t=1423163487; x=1424373087; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=38DooLEvHZxyZdLXmw0OjNwIZ0EE++/yiO+ndwc4Hc8=; b=YGZtl62MkqSW1nZUUSTi8E7K1/L4rHyIE6gsCkR+UnF+3DN0V5EMcfsm 0Imp7GLkUDULIquvid4HUtbqPGmVWKodb6AoHvgO+isS63ez4VpnJlBKz 677lz4kwxQVjAJ6cAdJoL8OGc9adROEgB4MT//yJ8C1xmo1YqPKxvpm4U s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFACa/01StJV2c/2dsb2JhbABagwZSWQTCQQqFJ0oCgSdDAQEBAQF9hAwBAQEEAQEBNzQJAgwEAgEIEQQBAQsDEQkHJwsUCQgCBAENBQiIJQ3WWAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjEiCfzEHBoMQgRMBBI8YnBcig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,525,1418083200"; d="scan'208";a="393796401" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 05 Feb 2015 19:11:26 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t15JBQtW025426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 19:11:26 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.73]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 13:11:26 -0600 From: "Alexander Clemm (alex)" To: Phil Shafer , Kent Watsen Thread-Topic: [Netconf] Notification updation RFC 5277 Thread-Index: AdAdmGPAceznqgnXSje9O6PD47W4GwKspEggBix6hTAAH2fEgAAEnTgAAABOrQAAAoyGgAAC/EgAAAuCRIA= Date: Thu, 5 Feb 2015 19:11:25 +0000 Message-ID: References: <201502051831.t15IVw5U056876@idle.juniper.net> In-Reply-To: <201502051831.t15IVw5U056876@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Rohit R Ranade , "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 19:11:34 -0000 Stability is all good, assuming it can be reasonably adapted to requirement= s. The other side of the stability coin would be inflexibility.=20 The need to adjust subscriptions appears fairly reasonable; we are also see= ing this in conjunction with datastore-push. So, I for one would think it = reasonable to look into extensions to accommodate such. =20 --- Alex -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer Sent: Thursday, February 05, 2015 10:32 AM To: Kent Watsen Cc: Rohit R Ranade; netconf@ietf.org Subject: Re: [Netconf] Notification updation RFC 5277 Kent Watsen writes: >>Not with RFC 5277 - there is no delete-subscription in RFC 5277. >Poor man's delete: drop the underlying NETCONF session. ;^) >The assumption is >that there is a dedicated NETCONF session for each subscription (no=20 >interleaving). Using SSH channels, this can be a fairly cheap=20 >operation, reusing the same underlying SSH connection. If we could have made that assumption, the notification mechanism would hav= e been oh-so easy. Instead we designed for interleaving notifications and = s. I thing it's too late to start requiring that assumption (un= less we want to redesign notifications (which would be a great idea (except= for my previous comments re: stability and "done"-ness))). Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Feb 6 00:30: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 D0A5A1A03FF for ; Fri, 6 Feb 2015 00:30:20 -0800 (PST) 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 XDQKMwycL3Gc for ; Fri, 6 Feb 2015 00:30:17 -0800 (PST) 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 2C5761A0108 for ; Fri, 6 Feb 2015 00:30:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOY88471; Fri, 06 Feb 2015 08:30:14 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Feb 2015 08:30:13 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.141]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0158.001; Fri, 6 Feb 2015 16:29:29 +0800 From: Rohit R Ranade To: "netconf@ietf.org" Thread-Topic: [Netconf] Delimiter usage for Notifications RFC 5277, RFC 6242 Thread-Index: AdBB5wNUNVWaykz8RIyEAmdQ3uDjvQ== Date: Fri, 6 Feb 2015 08:29:28 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A671E2F1C@szxeml512-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ALhd A+4D BDoq BFZC BNOX Bs7U B5wf ENoM GAhw GU3b Gid6 Gpd6 HoMK HxOd JVmy LzaH; 1; bgBlAHQAYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {EA523BAD-6E97-462C-B2D7-5005F45F6E90}; cgBvAGgAaQB0AHIAcgBhAG4AYQBkAGUAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Fri, 06 Feb 2015 08:29:24 GMT; WwBOAGUAdABjAG8AbgBmAF0AIABEAGUAbABpAG0AaQB0AGUAcgAgAHUAcwBhAGcAZQAgAGYAbwByACAATgBvAHQAaQBmAGkAYwBhAHQAaQBvAG4AcwAgAFIARgBDACAANQAyADcANwAsACAAUgBGAEMAIAA2ADIANAAyAA== x-cr-puzzleid: {EA523BAD-6E97-462C-B2D7-5005F45F6E90} x-originating-ip: [10.18.144.92] Content-Type: multipart/related; boundary="_004_991B70D8B4112A4699D5C00DDBBF878A671E2F1Cszxeml512mbschi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Netconf] Delimiter usage for Notifications RFC 5277, RFC 6242 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, 06 Feb 2015 08:30:21 -0000 --_004_991B70D8B4112A4699D5C00DDBBF878A671E2F1Cszxeml512mbschi_ Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A671E2F1Cszxeml512mbschi_" --_000_991B70D8B4112A4699D5C00DDBBF878A671E2F1Cszxeml512mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have a scenario where many notifications get generated in my device. When= the client subscribes for these notifications, I do not want to send him 1= notification per message. I want to maybe club the notifications and separate each notification using= the RFC 4742 specified "]]>]]>" delimiter. I do not want to move towards C= hunked Framing mechanism of RFC 6242. An example about what I am saying is like this: Multiple notifications in o= ne message. 2014-08-27T01:21:18 abc 2 2 ]]>]]> 2014-08-27T01:21:18 abc 3 4 ]]>]]> (1) RFC 4742 and 6242 does not mention that the message ends once the delim= iter is encountered and Client needs to ignore the data following the delim= iter. (2) It also does not clearly mention that a message can have multiple XML d= ocuments separated by delimiter. The only information which points towards (2) i.e clubbing XML documents i= s as below: [cid:image001.jpg@01D04215.1D05A500] This is done to remove network congestion due to excessive notification pac= kets. Kindly provide a conclusion whether to club multiple XML documents or= not. With Regards, Rohit --_000_991B70D8B4112A4699D5C00DDBBF878A671E2F1Cszxeml512mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have a scenario where many notifications get gener= ated in my device. When the client subscribes for these notifications, I do= not want to send him 1 notification per message.

I want to maybe club the notifications and separate = each notification using the RFC 4742 specified “]]>]]>“ d= elimiter. I do not want to move towards Chunked Framing mechanism of RFC 62= 42.

 

An example about what I am saying is like this: Mult= iple notifications in one message.

 

<?xml version=3D"1.0" encoding=3D"= UTF-8"?>

<notification xmls=3D"urn:ietf:params:xml:ns= :netconf:notification:1.0" >

  <eventTime>2014-08-27T01:21:18</even= tTime>

  <event xmls=3D" SomeURI">

    <f1>abc</f1>

    <reportingEntity>

      <f2>2</f2>= ;

      <f3>2</f3>= ;

    </reportingEntity>

  </event>

</notification>]]>]]>

<?xml version=3D"1.0" encoding=3D"= UTF-8"?>

<notification xmls=3D"urn:ietf:params:xml:ns= :netconf:notification:1.0" >

  <eventTime>2014-08-27T01:21:18</even= tTime>

  <event xmls=3D" SomeURI">

    <f1>abc</f1>

    <reportingEntity>

      <f2>3</f2>= ;

      <f3>4</f3>= ;

    </reportingEntity>

  </event>

</notification>]]>]]>

 

(1) RFC 4742 and 6242 does not mention that the mess= age ends once the delimiter is encountered and Client needs to ignore the d= ata following the delimiter.

(2) It also does not clearly mention that a message = can have multiple XML documents separated by delimiter.

 

The only information which points towards (2) i.e &n= bsp;clubbing XML documents is as below:

 

 

This is done to remove network congestion due to exc= essive notification packets. Kindly provide a conclusion whether to club mu= ltiple XML documents or not.

 

With Regards,

Rohit

--_000_991B70D8B4112A4699D5C00DDBBF878A671E2F1Cszxeml512mbschi_-- --_004_991B70D8B4112A4699D5C00DDBBF878A671E2F1Cszxeml512mbschi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=17347; creation-date="Fri, 06 Feb 2015 08:29:28 GMT"; modification-date="Fri, 06 Feb 2015 08:29:28 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABdAlkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2K4nj treS4lJEcSl2IUkgDk8Dk1SbXLIRWsmLgi8OIP8AR3G49gcj5c44zir00YmheJujqVP4iuK0XR9W tL/T7y6tJMSq0l2ocHymjQpEAM85U9vSjqHQ7CxvItQsobuEMqSqGAcYYfUVPkVyGk6dLZLpDQab c287pKt1KVGQSDjec8jOCOuPam6NpV7a6hbefBKskIb7RIlqiifIOd0m8lwTz0zn05oA7HNLXH6N pxsH0qWLSbmCUzzC4cqMrGd20N833clcAdMV2FAEMF1BcmQQyBzE5jfHZh1H60ywvo9QtRcRI6As ylZBhgVJU5H1BrE0vT4dM1a5VNBxJJctIl1HFGFWNgP4s59RiqljYvbPZXUelXUdy+oytPIVG8RM WxuO77vzLx7dOKF0B6HUrcBrt7fypQUQP5hX5DkkYB9eOnuKlzziuftmMXiqeaLSLqGOeJY3mESh WcM3zEg5PBHOKof2U83iCO7XTLuOdb0yM03lmPYCRuEg+fkYIUkgdMegugdzsKTIoP3TkZGOnrXA R6E8cQmh0O4jlVZXXCqGDiYMp+912ZA9ORxR1sHQ7/POKM84rjRpV+NWMjxTec135y3MdqhbYWyA ZC+QNvykY/DpVq504SXdyl5oct9cy3G+G5DhVCZBUb85QLjkAc475oA6Czvo70zhEdDBK0Thxg5G OR7YIqxkZxnmuRlsXWa+vk0m6N4dSjaKQKN/ljaCV+bhcK2RxnPTmm6pDqcmtC5TSzuhuoyJILZN 7RAjJ80uCcjOVx7UIH1OwzUT3AS6it/KlYyKx3quUXGOCexOePXBrlLzTMXOq3kOkXJuftkL28iI M4G3cyfNxnDZ6ZyOtaF85j8TWl3FpF05jR0luI4V+YMBtGc5IHP0oQmdBmjIrkNe0t9Q1Sdhpt40 2YxDIfLaF8YOd334xnIO0jOM81WutBFxf3co0WXMt1MdxVQGBiwp69N4z9SD70hnc1DLcCK4hh8q VzMSNyJlUwM/Me3p9aZpzSNptsZkkSTyl3rJ94HHOfesjV22a7Y3MWk3M727HzJ4YlOUKMMZyCeS OKb0YdDfzS1yPiTTW1O9mB0y9dzCqQyKI3jc8nBz80eCeSpGfXiuriDCJA4AYKMgHIBoAdmjNczr lnIJ9T8vSpLwahaKi+UqkGRd2C2SMdVwfb2qrrOntqSxCXTNQZhZqiOqxuu45yrK3KEcZZSOvXig DsM4ps0nkwvJsZ9qk7V6t7D3rkNU0i+a4R57fzozaxxosdsJ/IYA7tpZ1KnOCGHPHXirNzp8vH9o 6bcaoWtUjgOF3ROBhsnOFJODuH58UMEdHZ3Ud9ZQ3cO7y541kXcMHBGRmpq5yw1OfTbLw9pLafI1 3cx+XIjuFMKxr87nrkZwB67hXR02BDJdQRTxQSSBZJs7FP8AFgZNMN9GNSFiUcSNCZQ+PlIBAIz6 8j86ytf06CbUbC+m0ldQSHekgESu4BHHDdRn+dQXdlHfataNdaLM1vFYyARlVZEYkYXAOCcKcelS M6TOOtLXFT6fqNxZ6bNdWssqR2vlPBNbLOySZ5YqXHUD73J4966fRYZrfSLaKdpmkVcEzAB8Z4zg ntjuaokuk460ZA71g+JbUXj2scljd3ES72L24jcIeAA0b5DZycHHGPesc6ZHbT6HHeaO115VrOHh XDMF3JtLKThsZ6ZOCeOlJDO2zjrR0rj7zSb5re0c2xa0jMpW0eBZzEGI2ZQsAcDI6nGanXT7hNO0 8XdncX1pC0hktnRd3J+Q7NxBC8gAkkZHpQB0l1cC1tnnMUsoQZ2RLudvoO9S5AGTx9a5a+so18Lz 2sPh+dTM0jQW4CyNGx6McnCdegPFWdYkur7T7YR6WzxM581bi1WZ0IHHyFgOeec8fjQBr6jfLptk 928E0yRjLiJQSABknBI4qwjiRFdejAEVy8H2+DwVJZz6dePdMs0KxqikjO7b/EQFwQOvFdBpszT2 MTNbzQFQFKTKA3H0JoEWar3V9HaS20ciSH7TJ5asoyFOCefToap69byTx2xNs13bRzbri2TGZF2n HBIDYbBx3xWPLpkMsNtDFoNxBay6isrwgj7oUgsyg4Vc4+Uds8ULcZ1mRjOeKM1yjQ3iaZdWkWkt 9n+3Ntjmt1lCxYyCke4AjcOmRjOcVAbO9bwbf2M+mXLzGZxbxrEilQeVZQGIUD68GgDssj1ornLi 0WPRD/Z2jFRPKouI7iESOQP4yhbDtnHJOe/OKp2VlqJ0Se2msZxGl6JDb7VjEsBwSqqGIA77c+3e gDqrm6htLd7ieQJEgyzdcVKCCMg1y0+jW97o2qR2ugfZhMFaOKXaPMZR1CZIT07ZqS9s3vNEaHTd KawiSdHeBoUHnqPvDYGAPbgkZxigDpcjGc0VyUNhMnh/VomsbiVLhNsVqLVI1D4IyqbjjnBJ45Ga 1vDlnb29krx2M9tPsVJmuP8AWSkD7xOTnknmgDYpM56VR1xGl0e4jS2muS4CmKCQI5BIBwTxwOee uMVzcGiXX9m6kljbzQJOYSBNGiPIFPzrsQhcEcds5OfWgDsgc9KMj1rkLTTb37FeiKCeOOTyy1uL dbZXCtlwqhzyy8E8A8VA+lwXt/qkdpoxtGawjMMUiqpLb2OVUHC8gemSKAO2oyPWuTuLa91GfVja adc2LXdrEBJKqr5rKx3A4bOSpA5x9eKrx6ZOdM1VBYT7JrUotslmkCtJ2YKHPzD146D0o6AjtKM5 rlY9OuIZLu30uynsxPpyhZDhQ03PU5J34IG79eKDpguIbkaTosul3DWjRee5CZJI+XAPzHj7x6et DBHVZz0ormvDljPbak8n2eW2i8ra0YtEgjY5GCQHbLDnn9eldLQBV0/UE1COVkhliaGQxOkqgMGA B7E9iKbZ6nDdw3Ehjlg+zOUlWZQCpABzwTxgiq2gyxzPqckUiSIb5sMjAg/IncU3R542k1eaJhMo uyR5RDbsRpwPej/IP8/8zUgniuYVmglSWJxlXQ5BHsagsdQjvmuEWGaF7eTy3SVQDnAIIwTxgis/ TNOuRqb6kyDT4pQc2cZz5h/vSfwhv938Sak0aWObUtXeKRJF+0qMowIz5aelAmW7PUortrlfKlha 1fZIsqgdsgjBPGDU9vcQXcCz28qSxP8AddDkGszSpo5NU1mSJ1lVZk/1ZDciNePrUdjp91Lqp1Py /wCzYmzutkILT/7Ug+6D9OfU9qA6G5RWZo2rtrBvXW1MUFvcvBFKXz5+3hmAxwN2R+BrToGFFFFA BRRRQAUUUUAQ3U4tbSa4KM4iQuVXGTgZwM8VjR+L7KddN+z211LLqSu0cQVQ0e0fNvyQBzx9at6t qNmbC7tkvLT7QY2QRyXCp8xGMH0/KuetobK1urG7iksFnaRWvCdQUhdqFPkGO+dxxjJqbo09lO11 Fm7B4g8+PTpBp10qaicRlmj+Tgtlvm9ATxmlg8QLcPGyafeG2lLhLkKpQ7QSScNlfukDIGTWXYyx Rvp9vPf6ckGmZ8uVbtSZvkKL8v8ADwcnk80yxlh/tO3upn0mwlRi1xLa3oIuMgjbt44yQcn0p3Xc PZT/AJX9xo2ficXdxFEdKvYVkMY3v5ZC71LLkBieg9OK3GJCkqMnHAJxmuesNTiTXL+ee4sI7ecJ scXqsTtGOV7Zz61qNrOmBSV1GzJxwPtCjP60cyD2VS/wv7iHStes9ThiBlhiupASbbzgzrgkH69P SrUepWM121pFeQPcJndEsgLDHXjrXKaViGytLC5n0iBYbo3TTw3als7y2MYHzHOCc9M02ytoLW7t YZdTgmt7WfzUkOpIF6k52Bc55ORnnJ5o5kHsqn8r+47eqh1TT1vPsZvrcXOceSZV359MZzTf7Z0v /oJWn/f9f8a5pRBJqqTPLpcGy8M5mj1DcjDJ58o8ByOpHfJzRdX3D2VT+V/cdQupWL3hslvIDcr1 hEg3j8OtNj1bTZp1t4r+2eZiQI1lUsSOoxntg1ykVtDDdxwtqkM1sl156udSRVB3ls7Quc8468+v NSb41WV0fSxJJqq3RIvkyUBHJOOuBjH60KSB0qn8r+46GDxDpVxqU2npew/aYXEZQyDLMRnAGea0 q5waktrrF1Lb3WmywXbRsZHvVUx4UKRtwc9OOe9a39s6X/0ErT/v+v8AjRzLuHsqn8r+4gstetbi aS2uJIba5Sd4VhaYFnx0I6HmrLatpyRzyPf2ypbNsnYyriJvRueD9a5RPmTU7Z5tISPUrppftC3i l4l4AJGOWG3IweOPSp9RmsJ/EUcEOpWn2K7UTXw85cExkbOc4y3AI9FoutNQdKf8r+465WDqGUgq RkEd6zLfXrV7ue0upILWeK4MKRvMMy8KQQOOu4cetT/2zpf/AEErT/v+v+Ncw77ptYj8zR/K1SXi Y3i741CKoLDHPTIAPFHMrh7Kpb4X9x1cuo2MFylrNeQRzyfciaQBm+gqrJ4h0qLVX02W9hjuEVWK tIB94kAdevHT3FYtxJCFvrOK702eK/OWuZLtQ0fyheV/ixjI5/KrE2oJa6oLmzvNOuVkt0hYy3qo UKknceDkfN+lHMu4eyqfys0k1u2XU7iwunhtpI3VYt8wzNuGeBx9MVp1x1+8VwdbZJdMZ7yONIXN 6gLbRjnjgA8jrXRJrWmmNS+oWasQMr9oU4P1zRddw9lU/lf3DJ/EOl2uqf2bcXkUU4jD4dwOpwB1 60HW7aHVZrG7khtigjMTPMB5u7PAB7gj37Vn32pRxaul9ZXenXAa3MLLJeKm07sg98iqV9NFcz6v IJdLZrqySCJzepyRuyDxwMtnv0pcyD2VT+V/cdLc6lY2cyQ3N5BDJJ9xJJApbtwDVquJvY0lnlmT UYHW8gRJoU1GNApVcFSSp3Dn278V0lpqel29nDCdTtMxxqv/AB8q3QY6k8/Wnddw9lU/lf3Edx4g ht9Wm0s2tw1wlv58eNoWYc5Ckt94YPBx0qBPExk8ny9Ju286BJ1zJCvyscKOX6k9veszVmS91G8m t73Toz5Ef2S4a8XKypvPK/3TvKnnpmqrxQC4095V0y6+xWkMasNRVCsiEMSOOmR+NLmXf+tRulP+ V/cbs3iRUniVNIvZHkWMdI1KGQEhTuYc8c1OuvLNHB9m0+7nlliErQqFDRLnHzEsBnIPAJzg1l3u pyz2em5uNMmuIplmuMXyooI7Dg56+3SrNzqMFrqMl/Y3en3JuI1jkie8WMqVzgg8/wB4gj6U7oXs qn8r+4tf8JArrEsGnXss8kfmtb+WEeJMkZbcQASQcDOTTF8UWcl9bWkcFwzXcDSwPtAVyvVDk5Vu vBA6HmqX9oSWt2b+O90m5muIVjniF2I1VlLFSpOcjDEH8/as/wCzRG4SN9R08jyGJuVulBjnMnmh lX0DcdelHMg9lP8Alf3G0PFCtb2ky6XdEXSyMoLxLsCdSxL4HrWpY3bXtuZHtZrZg5QxzAZ4PXgk Ee4NcXLaw3Gm6RZ3z6XdLbxyC5C36qAzjHycc4z7V2A1jSgAP7StOP8Apuv+NO8e4OlP+V/cTXV7 a2MQlu7mKBCcBpXCgn05rL1W4sRbxa5BY2momEgCcOu5FzjKtg557ZFRajqFsNRttQtLzT7loY3j MUl0qY3EfMp5weMfQ1Sv7wPoDWVu2jiWcszpFeLGkeW3eh3H1OBzS5kDpVP5X9x0OqajHplp5zmL ezBY0kmWIOSem5uKlu720sIxJd3MVuhOA0rhQT6c1gazq32/Q2toX0/z51KuraggEfPHOOfyqHU7 hL97S/TULaC4gV0aCLUEXhiOQ5U88enejmQeyqfyv7joZdU0+BI3mvreNZVLozSqA6jqRzyOahvt f0zT7e2uJ7uIQ3ThInDrtbPfOelc/bi1hOlAzWDpb3Mk8nmX6OYywOCOACcsTxjFPimRdHjT7Vpq XEF8blYvtqlXXeWxuxwcN6dqXMg9lU/lf3HVQXEN1Cs1vKksT/ddGyD+NNuru2sofOup44I843yM FGfqao2muWkkG67vbCGQk/JHdK4A7ZPHNU9b1NZooRp+rWqgOTKqXaRuwxxhiCBz14puSD2VT+V/ ca0mqafFDFNJfW6RzAmN2lADgDPB78Up1KxFkL03kAtj0m8wbD269K5K22pYWNtcz6bMYNRa4kLX ysNpLEN90ZILdMDpU0MyxSNdfadOLxXss8cH25dsiuMZzjhh16dzRddw9lU/lf3HQ6VqiaoLlo1T bBMY1eOQOsg2hgwI9m6U7VNVs9Gs/tV7Ksce5VGSBkk47/n+FZGg3tvaSag13c6ZALm589FgulYc qoIPTnK8nvmrOs31je6XLBb6lY+aSrIHuFAJVg2Ce2cYo5kHsqn8r+4sXWu2sNtBdwSQ3FtJOsTz LMAsee+ehxVoajYmyN6LyA2w6zeYNnp16Vz+oaiNStbdZm0v5LuOUxG/VsIpzknGCc9v1qtdLFdf bGF/ZQEX63UHl3qAyAIF5ODtPGeh5xRzL+vkHsqn8r+4622ure8hE1rPHNEejxsGB/EVU1rWIdDs lvLiCaWLzFRjCASm443EEjIHfGTWZoNzZWQuZbnULdZLhwzb79JScDGeAoHb8qfr2oWt1awJaXdh OyXMcjK92qDarZPr6Youu4KlU/lf3E0/iQQyXKrp11KLcxjcjR4cSHClct0+uKX/AISEiMk6Veb/ ADUiRAY2Dls9GDbeNpzzxXOtarDaalare6ZdQTSQLbRveKuIUO4qx56cqPbFamkajHp9tLAjadBb RR/6Pbi/ViXLMWy2OByPWjmXcPZT/lf3Fy18Twz2r3EljdwKER41cKxl3EqoXax5yMYNSnX1hWU3 mn3tqYlUgOisJCxwqqVJBYntWVaSwt4dtbWe+0+C7s5FeMC7V0YqcjJ44PI6cU+51B9TgJlvdKtG gkSW3T7WJNzqc/MRjCkccDPf2ouu4eyqfyv7i5d+KIrC0uZrrTryOW2VXe3AQuUJwGXDYbnjAOfa ov7S02C/u7630hnlWzFy13EseZoz6EtnseDjpWbqVxJqSTXTXGmRz+WkUMAvlOB5iuzFsf7IAGKY IkhOreVf6a0N1Z+VaxG7UGNmLF1J6bQWyPY47UXVtxqlP+V/cdHYaw97cLE2nXMAZS292jZQRg7T tY4OGBwa0mYKpZiAAMkntWB4fn0nTNO8oT2NozvveNLtXXdgDIPHXFWtS1Swn025hgvdNllkjZVj nnXy2JHRsHOKG10YlSqfyv7i3bapp94H+zX1vN5Yy/lyq20epweBS2+p2F3DJNbXsE0cXLvHIGC8 Z5I6VyaWlpcw30bX1lZLcWwhAN+J2JByPmbkL22+/T1s6ZcR217Nez3lu8wgMaCTU0fdzkDhQAPc +tF13D2VT+V/cb/9taVtL/2labVj80nzlwE/vdenvTo9W06WWOGO/tnklTzI0Eqkuv8AeA7j3rB8 OTWFnpn2K9/suHbuJZLtJPMLkls8CoLW2t3sb63vdasQzQGztJI7hSVhGcE5/iORn/dFF0Hsqn8r +46SxvdMmikFhc2rxx8uIHUhfc4os7/SnZILK6tGaRTIscLr8w7kAVzulyxW1/8Aari9t2eGBo49 +po4bOOAAowOO/T0qfw5dWdjDJFdnTLdjNJN5sd4jlmdieeBzg4zRddw9lU/lf3HT1UsbvTZ/MTT 57Z9hzIsLKcH3AqOfWLBreQQarZLKVIRmmUgNjgnn1rndKnlh1qO9vdRtJEFu8Ts+oo7biVOQAoA Bx0zRzIPZVP5X9xqab4gsrvUZ7awWy8iJ2Eki3ChyQMlggHIycZzV3S9f0zWAfsV3FI4LAxhwWwp xnAPT/GsvRNVWCe6W8l0+GOed5g6X6ORnHGMD0pLG+WGObT5L3TktmaU/aUvV3EOSRhccEbvXtS5 kHsqn8r+427XUNPuZXgtLu3lePO+OKQErzzkD3pItW02aSOOK/tneQkIqyqSxHUAZ7Vy+kxw2l5Z /aNRt3jslKxudSQr93bwgUHn0J/PFWdEura2vb2S7GmRfarhp/OW9R2zgBQRgdMGnddw9lU/lf3H V0VUj1TTppFjiv7aR2OFVZlJP0Gat0XuTKMo7qwUUUUyQooooA47RdH0vUdX8QS39jb3DR35AaVA do2g96t2mm+Eb2ZYodItwXBaMyWZRZQO6EgBvXik8ORJPfeJYZBlJL5lbHoUAqXTfDDWF3E+62KQ KRG4RzJ93aD8zlQcHsPyrKnGLWqPRxderGraMmtF1fZCQaR4VnuzajRYI5cEqs1mY94HUqSAGxkd PWoFs/B8twlvHpVvumcxxSGyby3YZ4D4weh79ql0/wAM3dnqlveSXcMnlK6SEpIXlDAZYkuQDkdh jk1ds9N1SzWG1TUIfsduMIBB+8dR91WJOMe4AJx2q+SPY5frNf8Anf3sx9EtfDGpQwxzaRZLdPvU 7bUrGzKSGCsRgkY6ZNa7+FvD0aM50W0IUE4WAEn6DHNR2mi39vHpaNdWzfYpXeTETDeGBGB83H3j 1zW3IHMbCMqHwdu4ZGfejkj2D6zX/nf3s5K1Hge9kijg0yAmYrsLWLKPmOFOSuACQQD3IxVmHT/C E9yIE0m2yzFEka0Ijdh1CuRtJ4PQ9jSweG9QhhhU3tsWjjgXPktgmKQuP4uhBx9fypbPwoLO9hZP szW8Em9C6yNIOcj+PbkeuKOSPYPrNf8Anf3siFn4NN6toNLtjI0phVhaHYZB1XdjGRg9+1Bs/Bov Raf2XbeY0vkhhaEoZP7u7GM/jVuPQbttTS7uJ7QlJjL58Vr5c7DJwjMDgjBAPHOKBoN2+prdTz2Z KT+aJorXZOVycIWBwRjAPHIFChHsDxNf+d/eyI6R4VW+Fm+iwxyM21WezKo5xnAYjBOM9+xqvNb+ C7ecRPpUBLSiFGWyZleTONoYLgn/AAPpUx8MXh1SK9+2wuYrnzw0iSM7g5G0/PtGAcDA7Cop7O9h vbPS7eRpLWC8SYAWjghMliGlPyYGe3PQetChHTQHia+vvv72Sf2f4QN39n/sm2yJPK8z7IfL3/3d +Nuc8devFX/+EU8Pf9Aay/78iqX/AAigS+Lxm2aBpvOxKsjOCW3EffC9enHH4V0lHJG2wfWa/wDO /vZzOoaJoNtfWFnDodi8t3KQd0IwqKMsfr0A9zVGex0yG/bTf+EY003jzAW8faWH+KTOzjb3HrgZ 5Fb+pWc7avpeoQIZPs7vHKoOP3bjBP4EKfpmqs+hahNeTX4vLcXomU2spibEMQ6xkbuQe/TJOeww KEewfWa/87+9nO3VxoVpb6gH8K2TXdrceVBCMYnXJG/O3gDDZ4OMe4rXttD02XWpbKXw7pSxRxLJ 5icsd2QBgqB1U96mk8NXU9ndLLJYteSvL5Nx5DfulkOXH3s9h3HSpbnSdblubqaG9sovtNusGfJf cgG75gd/X5j+Qo5I9g+s1/5397LH/CKeHv8AoDWX/fkVi67a+GdLs7ow6RZG4t03EtZs8SnqFZlG AT7nuK66FDFDHGWLFVALHvgdaxdQ0O+ngv7SyvYYLe/3NIZIS7qzDBx8wGDjuPWhwj2GsTW6zf3s q3Gn+EbWYxTaTbbkAMpS0LLFnpuYDC/jRe2Hg+wdkm0m3Yxp5khiszII19WKg4HXrV2TSdQxcRw3 dukV6B9oBiJIbaFYod3GQO+cU46Te2s0h0u8hhjnVFcTRGQoVUKGXkdgODnpRyR7CWJr/wA7+9me 9j4PjhuJTpNuUtlR5CtmThWGQw45GO46YNQzx+Cre6ktZNJi82NghVbB2yxG4AELySMkY7A1o6jo d/cC6W1voUF5brDM80JZsgEbhggc56U0aHqLXhuJLu1/16S7ViYcCMxkfe9Dkf1o5I9g+s1/5397 Kstl4Oi2n+yraRWjWUvFZl1RG5DMQMKCOefSkurXwZZ3LW82lW/mLGJSEs2ceWf48hSNo7ntR/wi EojjPm2ssnkpFKZEk2nYNoICuOoxkHPSr0uiXe+4EM9qkUlgtpGvkt8mM8/e6cnj6c0ckewfWa/8 7+9mfd2fhi01OGzPh1JRNC0okhsmkGARjG1Tnr+H41Ld6LoNpqVhC2h2P2e9LR7zCAyybdyj6EBv xxV99L1BBYzW11brc2sBhfzIWKMDt5ADAj7o7nrS31ldXeo6Sj/PFaubiaYYUM4UqoAz3LE/hRyR 7B9Zr/zv72H/AAinh7/oDWX/AH5FUNS0PQLJ7VF0ayUzzohZ7RmXBIBGVGATnjPFdNWXrNjqF8IU tJ7aJI5ElPnRsxLKwYdGHHFHJHsH1mv/ADv72Zl9YeENPultbjSIPOeMyIiWTOWUdSNqnOO/pV2H w14auIEnh0mxeORQyMIRgg9DUsmn6hJqMd4Z7UFbRoWXym5diDkfN0yBx+tWdJtJbDSrazmkSR4I whdFKg44zgk0KEewfWa/87+9mDqeneG9MvbS2fw7HL9pLfNDZl9uAT/Cpz06VFeaf4estSs45NDt TBdQO6otkzTblK/wgZxhuRjjFdBqdjcXMlrcWk0cc9s5ZfNQsrAqVIOCD3qH7BqJ1G1u3urdzDBJ G/7kgszEHI+bgDaOOe9Lkj2D6zX/AJ397M6XTvCEcUEi6TbTi4XfGsFoZGZe5woJA5H51bt/Dnhm 7t0ng0mxkjcZVhCOap/8IpMbS03zW8l1bxtEWKSKjKW3dFcEH8TW3pdiNO0+O2AiG3JPlKVXJJJw CSe/c0+SPYPrNf8Anf3s5zVtP0LStUsbZvDlg9vd7g0+0AwkYAJGPuksoznjNZ86aXa28U1z4e0K 3R5p4meWUhV8vOT/AKvnO08fSuq1PSZdR1CCQyQ/ZVhkhmidCWcPjOCDx90dqzV8MX8VjZ2xvbW7 8hpmla5tyfN8wnqA3o3PqaOSNth/Wa387+9lC9062tLETnwjphKpI8hLfJgMAuCEPLA55AxiphpN h+7tW8K6cL6SRwqH/V7Fxl923OPmAxjrWrcaVqtzok9k97bGedyd5hbYidlUbs8Y9atXNjdzfZrq KeGO+gUruMZMbBsbhjOccAjntRyR7C+s1/5397ME6TYK0dq3hPT1vpXcIm5TH5agZkLBcgZIAGM1 Uuk0WyaAXHhaxXFyYLzGCYcLu8xfl+ZcYPY47cV0T6XqLmG7OoRm/hZsEw4i2NjKbc5x8oOc5yPw qBtAvGngne6t5XM7TXXmQnEm5PL2qAeAF45zRyR7D+s1v5397MSe2023tZ5pPDmip5N8tqWeTamD j5idnH3hWlo+haRqEBnm8P6YsLhWglgG9ZVI68qCPyp0fhi8tdM+xwX8MpF8LlWuIS3yAjahwwyQ ABnv6V0FpAtraRQKiII0C7YxhR9B6UckbbA8TW/nf3sxr3QvC9hEsk+j2vzttRUtt7OfQKASartY eEEtFujpFv5ZlELD7GdyOeMMuMr1HX1Famt6OurQw/MqywPvj37tpJBBB2kHofWqS+H7yLTJLOCa zh+0yg3O2FzvjxgqCXJyQMZPT0o5I9hfWa/87+9kA0/weYJ5/wCyrYJbymFibQjc+cbVGPm544zV K9h8Lx24nt9Is1ENzFFcpPZMrqHPGAQDnkY4Na8OhXcNkLZbuFVtZxLYARH90oyAj8/MMEjPB5p9 xpmr3UKedf2xkW4jl2iAhFCHOB82cn1J/Cjkj2D6zX/nf3srRaT4VntJLmLRYGETbXjFmfMU8cFM bs8g9OlQy2fg2Gwa+l0u2jhSQRSFrQgxsegZcZXqOvqPWrdzod9cC/H2yJBc3CzKqo4yoAXY5DZI IA6YqvB4av7fTrm1ju7TM91HcDMLkJt25XlyT90c59aOSPYPrNf+d/exE0/we9rLcf2TbKsTiN0e 0KyBjjA2EZJORjjnNRxW/gyVbgrpUANqVWVWsmVlZui4K5LHjgc8ir1zpF0Li8vmuYgfOS4g2QMx Qou3DAHLAjPTB5qla6Tca1HqUl6xBmnikhdoHhGUUfwEhtufUgnnHajkj2D6zX/nf3stWWieFr8P 5Oj2weM4eOW18t1z0yrAHmrP/CKeHv8AoDWX/fkUaNoz6aZ3b7MskoC5hR+gzjJZiT1PFW9Jt7+1 06KHU75b66XO+dYhEG5OPlHAwMD8KOSPYPrNf+d/eyp/winh7/oDWX/fkVW1DQPDun2b3B0K0kII VEWJQXZiAo/EkV0FVr+zW/s2gZyhJDI69UZSCp/AgUckewfWa/8AO/vZz0Wh6bA0jar4a0u2to4j IbiNg6g5+6QVBz3z0pfsfg8W0876PDGtunmSLJYsrhP720rkj3HpWlJpupX0E0WoX8OGUCNbeHaq sGDBzuJJOQOOBUVzo+oX0Ny1zdW32mW2a2jKQsERWI3Egtkngdx0pOEewfWa/wDO/vZVtdP8HXaS vHploqwoJGMttsGw5w43AZXg8jio4rTwbK7odKt4ikRmJmsmjBjHVgWUZHIq9NodzdzzfabiHyZr JbZhHGQwYc7gSSMZPTHpUkulX+o209rql9E8EkRj2W8JTJ/vEkk5GOgwKbhHsCxNf+d/ezN+yeDx bzzvo8US28fmusliyvs/vBSuSPcU62sPCN2rGHR4WxH5ig2TKZF9UBX5vw9RUdzoMtjpepTNHDJI 9nJDGLaGVpGLDpyzd8cAfyrT0u0u5za3d7cLIIIysIFu0LZIwS4Y9cDpgfyo5I9g+s1/5397MrTb Xwvf6Wb5vDqwqsXmuGsW6ex2/N+FXItH8KT3KW8ekWpeSHz0za4DJxyDjHccdeat6fpV7bWhsJ7y F7RY2jQJCVcg92JJGQPQVXg0TVFniaXUIFSG0e1QwwFXAOMPkseRtHGMUckewfWa/wDO/vZHa6R4 WvJ2gTRYI5lXdsmszGSM4yNwGRn0qPS/D+kzzXsF3o2ms9tMEVorfaCCqtyCTzzUuk+HbzTdTF6b m3b9w0LKEkJY5BDbmc85HNW9NsdVtb26nubizdLlt5WOJ1IYKFHJY8cUckewfWa/87+9mbp+g6Q8 2oQ3mjac5tJAFaC2xuUqG6Ek557UsNj4QnjspI9IgZb8kQf6Gecdc8fL0PXFaGn2Wp2d9dXV3cWk kdwQ7rDC4YEKAMZY56elU9AtVl1q/vBHcR20blbSKeBo9m/DSMu4Dgt+WD60ckewfWa/87+9l3/h FPD3/QGsv+/Io/4RTw9/0BrL/vyKfoo1Vvtk+qPjzbl/s0GF/dQg4UEjqTjdye+K1KOSPYPrNf8A nf3s4/WNH03TPEHh97Gxgtme8YMYkCkjYa7Cub8Tf8h3w5/1+N/6Aa6SpgknK39aG2JnKdKk5O7s /wD0phRRRWhxBRRRQBzXhgkan4jIXcRqBwB3+UVd0XVL/VIX+0afJa/PIglDxkDaxUDAJOePTHFU /C3/ACFfEX/YQP8A6CK0bfR3tZ3aHUblYWZ3WDCbVZiSTnbk8kkAms6e33/mdeN/jfKP/pKKeha/ Jc2dmt/DOjzRsVuJFVVlK/eOAcjjnkDNS2PiezvrmGERtGtySIHaRD5nBPQMSuQCRkCnW/h4QLp6 G/nkWxDgBkT94GGMNhfQ9sUWPh2HT7pJIbhhFF9yLyoxgdhuC7iB9a06nIbFc9barqMmrRQXE8Fv vmdWtZbZ1JQA42SZ2uxwDj0z6V0NZMGhtHLAbjUru7it38yKOfacNzglgATjJxk/yo6gU4dV1F9X jgnngtt07Ibaa2dSyDOCkudrMcA49M+lV7bX72W7tbZrlDI9/JBIPsTqvlruxhydufl65PXpxWpD obJLCbjU7u6igk82OObYcNzglgMnGTgE+npTI/D7Rpbr/adwwgumuRlI/mLZyD8vT5m9+aFugfkb Nc3b3HiRtQEEs9nvWOOWSEQEfKzsGAbf2UZziukrPj0yRNZk1E30zB4xGYCibQoyRzjPUnvR1DoQ /wBvFtTn09NNu5Jbdl8xlC7QjdGzn9OvHSnS65FBqqWE0LJ5jiNJPMQ5YjI+UNuH1IpbfSJrfVZ7 4anOwnYF4THHtIAwBkLnj61UPhSD7atyl5MhS4+0KBHHncSSQWK7iOT1Pp6UAyWPxGj3TQtp91Gk dz9leZguwOfu9Dkg5HIHGeaS48TW9vq4042s7SGVYsgqDlschSdxUZ5IGOD6UreH2ZJF/tK4HmXg u87I+GBBC/d6cD3460+TQmmnczaldy27ziY277SoIIIAONwUEDgGhdLgyOPxIHe4J027SC0mMU87 bNqEd/vZIwQSQOPwqWbXY4pZSLSd7WB9k10u3Yh78Z3EDuQPX0rP0/Rrua51EXZu7a2uLppDCXiZ JlOB2yy5xyOP51oTaEkskqi7nS0nffNaqF2OT15xuAPcA+vrQDEuNdMGqSacmm3c8yxrKpiClWQk gnJIxgjGDye1MTV79tduLEaXI8EaRsJBIgxuLZJBbOOPTPBqY6TN/bDaimpzruVUMIjj27AScZ25 6k85p11pLT3xu4b+4tWkRUlWLbhwpJHUEg8nkUdgZo1l3ctzDr1gqXL+Rcb1eEqu3hSQQcZz+OK0 6zL3SJ7zUIrtdUuIPIJMcaRxkLkYPVSTQAalrkWl3CJcQt5TYzKJE4ycfdLbjz6Ckutejs57+Ka1 lX7FAJ9xZAJVOfu8+oI5xzj1qvqPhW31G4nma7miNwVZ9scZO5cYIZlJA4HGcdfWmarp8+o63pqv YzNb2rlprnzEAkGAQpXOSNwUnjqooAfceKre2dlltZVMKK9wGkjBhyN2MFssQOTtzVi711ba9t7W KyuLprqIyQNDtKvjGRkkbeGBycD8abe+HoLu8e6jmMDy483EMb7iBgH51ODjjj0FPuNHmmv4LuLU 7iAwRmNUVIyMHGc5UnnaKANGKQywpIUaMsoOxxyvsfesyfXJI9TnsItLu7iSBFkZoym0o2cEEsOc g8deK1q5+XTr+fxNdTxvd2cEkEcYniaIq+0sSCpyQfmGDj1oDoWr3xDBZ2sN2ImltpYzJ5gkRcKO T8rMCeOwzTdW8SW2k+VvhllEsZkDAqoI9AWIBb2HNQ3vhKzu8qs0sEbW4t2VURjtGcYLKSp5PSrM ujTvs8vV7uLEAhdQIyrgZ+baVIDHPUUARaj4lt9Nht5Jbaf/AEiLzQGKptHHGWIBbn7oOaLjxLBA 0KLbSvLJAs7Rs8cbRq3QHcw568DPSpZNEYeUtnqV3aRxQCARLtdCo74YH5u2ajn8M2jrB9ncwNDC sIYxpJuRegO9T05596AG3vimytLS1ukR5orpDJG4ZUXHHdiBnnp16+latnci8s4bpY3jEyBwkgwy 5GcEetUZNHmzCbfVru38qLyiqhCrjOclSuM+4xV2ytIrCyhtIARHCgVcnJwKAINT1L+zY0kNuZQx IOJUTH/fbDP4VVl8QIHsltbG5u/t0JlhMe0AgYJB3EbeCOv0p+qaDDql1HcNO8TpGYzhEcFSc8bg cH3FNttBNqbHy9QuCLGBoEDKnzA9z8vUYXpjpQA+LXYZpdPCW83lagrFJTtARgM7W5zng9M9DVjS tRGqWQulgkhRnZVDlTuAONwwTwccViaro91F4di0a0iurxg6lboPEjQ/Nkt1XkAnGB9a6OCGO3gj giQJHGoVVHYAYApiK17qP2WaO3htpbq4kUsIoioIUdWJYgAZIFZun61cLoQvLiOSd/tEseJGjhYA OwG7JAzgY4rSvdON1MlxDcyWtwilBLGqklT1UhgRjIBrN/4RSEQxJ9uuHaGWSRHlSOQ/vDlgQykH nvjPOOlIY688QS/YdOvNNsnuY7ycIRuVSo5yOWHOR7jir1zqMtrp6XUlmwcnDRNNGpX6sW2/rVaL w9HBpEOnR3twBby+bDNhN6EEkdsEcnqKW78Pi8itxNfTyTQMzCWRI3zu6/KV2/TjigC9p9/DqVjH dwZCPkYOMggkEccdQelVfEN/dabotxdWcBmmVcLgqNuf4uSM49Kl0jTE0iwFnHPJMiuzKZAuRk5x wAOpNGracdVsWtPtUlsrn5mjVSSPT5gaGBVhvrmxtIluo7y5u7iQrFBJ5O84GTymFAwM5JqRNcjZ 4I2tZo5JJ/s8iNtzC+3cM88gjoRmny6XJNBCJL+Y3UDFo7oIgYZ4IxjaRjjpUbaEjW237XMLnzhO brC7y4GM4xtxjjGOlAEUviNYrcStp90zfazaGNNjMH7fxdDx9O9Srr0bW+RaT/aTMYBa/LvLgZPO duMc5z0qFPDjIgB1S6c/axdlmWPJbHT7vSpBoIBmkF9OJnuDcRy7UzCxG0gfLgjHHOaP6/L/AIIf 1/X4Bod/c3txqS3Kyp5FwESOZVDRgopxleCMk4PNaF5JLDaSPDE8sgXhUKg/+PED86raZpR06a6m N7PctdOHkM23hgoXIwBgYA46VZu4Jbi3McNy9sx/5aIqscfRgRQ9gRnf20LTw9Z6jLHc3YlWIMUR RIS2BkqDjqRwPWrmn6gL4TK1vJbzQPskikKkg4BHKkgggiqS+H5F0mLTjqlyUheNo3Mce4BMEL93 GMgds1cs9PNpe3lybmSX7W4coyqAmBjjAB6Adc0+rFrZFfxDez6dYRXUDyArcxK6RoHMis4Urg+u e2KZJ4iitoZjeWs1tPEUAgcpl95wuCG24JyOTxg5q1q2lrq9qls9zNAqypIWhIDEqdw5IOOQOlV2 8PwzxTC8uZbqaXZ++kVMptOVwANvBJPTnPNIZXl8S+ZpV/NaWxa7s4t7QGRG4IOGyGwRwe+eDU7a zcQaal3caVOhaSNNgkjJO4gA53Yxkjvmn22hxw2lzbS3DzJcoUbEaR4BBHGxRzz1praEZ9MubC71 K7uEnj8sOditGB0K7VAz3yaAI7nxRZ208ihGmhSHzfPidGQnfsCD5uu7I9ODzxSJ4psvs9zJOjRS Wyq7RCRHLBjhcFWI5PHUUy08H6XZw3kMXmmK7EfyMQRFs6FeOPm+Y5zyTU0XhyAWs9vcTtOk4AI8 qOMLg5BAVRzn1z0oAjHim3+y3crW0nm2kXnPCkkbsY/7wKsQeh4zn8xVzT9VF9PJA9pPayIiyBZg uWRs4PBOOh4PIqqPDg+xXVsb+UfaY/LLJDEm0d8AIAT9c1bt9MaDUmvWvJZS0CwlGVAvy854Gc5J 9uaALN3LJBaSyxRGV0UlUBA3H6nisaPVtQu/C0989tJYzCz85JQUcFtueBk8fWt1lDqVYZBGDWSm gOmny2P9q3bQvAYIwQn7tOnHy8nHGTmkMS38RRC2eS+t57QxWwuD5oHzp6jBODnscHmpNN1+DULr 7KYmgnKGRUaRH3KCAeUY4IyOD60j6BHPNvubqWeNrT7K8TKgV19eBnOfwp+m6KNPuDL9qaX5doXy Y0/MqoJ/Gq6k9DTrN0ea4d7+G4uGuDb3JjR2VQduxTg7QB1JrSrO0i2uoDey3UccT3FwZFRJN+Bt VeuB/dpdRsZpc1276jBLcGdoLjZE8iqMAorAHaB3JpbXVybtbDUIfst4wJRc7kmA6lG7/Q4Io021 u4zqEtwqQPdT70Eb79o2KoOSBzxnGKmsdLt7BnlXdLcSf6y4lO6R/qew9hge1AEOlzXLX2pW89w0 6wTKIyyqCAUBx8oGeTSabNdHUNTtpblp1gkTyi6qCoZQcfKBkZ/GnaZbXUV3qFzdRxx/aZVZFSTf 8oULknA646Umn2t2l7qNzcIkP2l18sI+8gKu3J4HPtQIINXaO7jsdThFrdS5ERU7o5sf3T6+xwfr 1rTqlZaVb2cjTkvPdOMPcTHLkenoB7DAq7QM5vxN/wAh3w5/1+N/6Aa6Sub8Tf8AId8Of9fjf+gG ukrOPxS/roddf+DS9H/6UwooorQ5AooooA5rwy4j1LxG7dFvyT/3wKu2l/ql99nlawhWxu1zvW5I kjUrlSRjqeOh4zVPwt/yFfEX/YQP/oIrRi8P6dDKsiRyjy8+UhmcpFnglFJwp57dKzp/D/Xc68b/ ABn6L8kZ3h7VL77LpsF9CClzGwjlMxeQ7RnL5Hce596nsPEYutZFgfs8qybzHJAzEfL65UA/gTVq HQLCAWgQT4stwhDXDkDd1zk/N+OaSDw9p9tcwXEYuN9tkQhrmQrGpGCoUnGOnHsK06nIRWOqapd3 1xCbCBYrW48mWXzz8wwCCo29gRnOPbNRWviMT62th/o8scrOsckDMcbQTzlQO3Ynmr1notrYXMk8 L3JaViziS5d1YkAZIJIzgCo4fDunQXEE8azhrZiYR9pkKx54IC5wBjt0oAjttU1O8MNzb2EDWMsu 0M0+JFTJG8rjHbpnPNM0e61m4vLxbpbQ28V0yAo7blAUYAG0A9fWrS6Dp63InEb/ACyeasRlYxK/ XcEztBzz0607+xrP7cbwLKJGcSFRM4QuBjcUzjOAO1AMybLxb9svYlW3UwTymNAm8yLzgMw27ccc 4PGauRapqk2rXdlHp8JS1kTdMZyAyMMjA2/eA5Pb3q0ujWiXPnoZ1w+/yhcOI92c52Z29eenWkg0 W1tr+S+jkuvOlbc+65kKscYGVJxwOnFCAoz67fwawlq+mhLd5xCJXZhkH+INt2/8Bzmt6s2PQNPi uTOiS8ymbyzO5j8wnO7YTjOeelaVHQOpiWV1rMuuX8Mi2htYZUA+dtyqUB4G3BP40Sa3dIst6LSI 6dBKY3cynzThtpYLjGAe2c8Vcm0aynvTdssokYqXCTOquV6FlBwce9I+iWL3RuCkmWfzGjErCNm/ vFM7SenbtQBoViW91rMniG9t9to1pF5WAXYMqnOSPl68etbdULnRrK6u/tMiyiRgofZM6LIAcjcA QDjJ60AZS6lfWF/qbmHzrKK8RWaScl13qnCAg8AtnGR1OKS68W+RqE8UduskVvL5TqN5lcjGSoCk cZ6E84NaUugWM6XKObgi6lWWXFzIMsOmOeOg4HoKkm0a0nnMpa4Qtjesdw6K/bLAEA8cUIC91FcR qWqa9btq9va3EziaVxa3HlBhZ7FDOCcY6H5c9+Oa7es7+wrLyLyHNxsvWLTD7TJyT1xz8uenGOKT GZMvip7OV4FiE4tVVZd5cyyttDHaFQgnBHUjJ9Ktazr19pzloNMM0CxiTzHLAHPUZCkJjuWx1q4+ hWTbcNcphQjbLmRfMAGBuwfmOOMnmkn8P6fcXMlw6TBplVZVSd1WUAYAZQcEY4qmJFXWtcvtNYtb 6b58KxeYZSzbW9RlVIXHXLYHP1pNY8SDS5FKm2lVYxJJHvYyYPphSOnTJGauXGgafc3Mlw6Sq8yq kojndFkUDADKDgjBP50l54e02/aQzRyhZlCyJHO8auAMDIUgHA/lSAg1HWb2Bb2SxsYriKwTdN5k 2xmO3dheCOhHJ9ap3XiuW3mEAggMkUKSTAvJ8xYZ2phD27nHUVPrfh86hEYbeNMTReTNJJdSLkYw CyrxIQCfvGr8ujW0/llnuEdECF4Z3iLgdM7SM9/zoApanr17awQ3Fppck0UkHnFnDgg9dhCqSpx3 PFa9rN9ptIZyFHmxq+FbcBkZ4Pf61Tn0CwuJhMROjiJYSYriRNyDOFODz1PWr8UaQxJFEgREUKqq MAAdBQBma4rI1jOks0bi8iTCSsqsrMAQVBwfxpuu64dIKBGtmbYXaOR3DkD0CqfzNWdQ0e21N42u HuR5ZBURXDxgEHIOFI596ZcaFY3WDN55PlCJytw6mROeHIPzdT19TSDqQy648VxZvJFFFY3du0om dyCrhd20jGPu5Oc/wms9vFV1HHapLa28NxNALhlkeQqqkkKPlQnJxk5AxVnVtDnu7G00q2ht3sIZ I2f7RM5k2o2do4PoBknpkVqXmm2966PIZY5EGA8MrRtj0ypGR7UwM6fXrr7Hpt1aacZBfSeWYpXM boxUkHkdBtOfbpmta2e4NurXcccUvRhG+5evGCQKp3GhWVylujtdKLY5i2XUikHnkkHk8nk+tP1H RbDVtPWwv4mngRkcBpGyWU5BJByeRQBfooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDm/E3/Id8Of8AX43/AKAa6Sub 8Tf8h3w5/wBfjf8AoBrpKzj8Uv66HXX/AINL0f8A6UwooorQ5AooooA5j/hHNattRvrnTtcjto7y czNG1qHwcY6k+1Sf2V4r/wChmh/8AF/xro6Kj2a/ps7HjKr3Sf8A27H/ACOc/srxX/0M0P8A4AL/ AI0f2V4r/wChmh/8AF/xro6KORef3sX1ufaP/gMf8jnP7K8V/wDQzQ/+AC/40f2V4r/6GaH/AMAF /wAa6OijkXn97D63PtH/AMBj/kc5/ZXiv/oZof8AwAX/ABo/srxX/wBDND/4AL/jXR0Uci8/vYfW 59o/+Ax/yOc/srxX/wBDND/4AL/jR/ZXiv8A6GaH/wAAF/xro6KORef3sPrc+0f/AAGP+Rzn9leK /wDoZof/AAAX/Gj+yvFf/QzQ/wDgAv8AjXR0Uci8/vYfW59o/wDgMf8AI5z+yvFf/QzQ/wDgAv8A jR/ZXiv/AKGaH/wAX/Gujoo5F5/ew+tz7R/8Bj/kc5/ZXiv/AKGaH/wAX/Gj+yvFf/QzQ/8AgAv+ NdHRRyLz+9h9bn2j/wCAx/yOc/srxX/0M0P/AIAL/jR/ZXiv/oZof/ABf8a6OijkXn97D63PtH/w GP8Akc5/ZXiv/oZof/ABf8aP7K8V/wDQzQ/+AC/410dFHIvP72H1ufaP/gMf8jnP7K8V/wDQzQ/+ AC/40f2V4r/6GaH/AMAF/wAa6OijkXn97D63PtH/AMBj/kc5/ZXiv/oZof8AwAX/ABo/srxX/wBD ND/4AL/jXR0Uci8/vYfW59o/+Ax/yOc/srxX/wBDND/4AL/jR/ZXiv8A6GaH/wAAF/xro6KORef3 sPrc+0f/AAGP+Rzn9leK/wDoZof/AAAX/Gj+yvFf/QzQ/wDgAv8AjXR0Uci8/vYfW59o/wDgMf8A I5z+yvFf/QzQ/wDgAv8AjR/ZXiv/AKGaH/wAX/Gujoo5F5/ew+tz7R/8Bj/kc5/ZXiv/AKGaH/wA X/Gj+yvFf/QzQ/8AgAv+NdHRRyLz+9h9bn2j/wCAx/yOc/srxX/0M0P/AIAL/jR/ZXiv/oZof/AB f8a6OijkXn97D63PtH/wGP8Akc5/ZXiv/oZof/ABf8aP7K8V/wDQzQ/+AC/410dFHIvP72H1ufaP /gMf8jnP7K8V/wDQzQ/+AC/40f2V4r/6GaH/AMAF/wAa6OijkXn97D63PtH/AMBj/kc5/ZXiv/oZ of8AwAX/ABo/srxX/wBDND/4AL/jXR0Uci8/vYfW59o/+Ax/yOc/srxX/wBDND/4AL/jR/ZXiv8A 6GaH/wAAF/xro6KORef3sPrc+0f/AAGP+Rzn9leK/wDoZof/AAAX/Gj+yvFf/QzQ/wDgAv8AjXR0 Uci8/vYfW59o/wDgMf8AI5z+yvFf/QzQ/wDgAv8AjR/ZXiv/AKGaH/wAX/Gujoo5F5/ew+tz7R/8 Bj/kc5/ZXiv/AKGaH/wAX/Gj+yvFf/QzQ/8AgAv+NdHRRyLz+9h9bn2j/wCAx/yOc/srxX/0M0P/ AIAL/jR/ZXiv/oZof/ABf8a6OijkXn97D63PtH/wGP8Akc5/ZXiv/oZof/ABf8aP7K8V/wDQzQ/+ AC/410dFHIvP72H1ufaP/gMf8jnP7K8V/wDQzQ/+AC/40f2V4r/6GaH/AMAF/wAa6OijkXn97D63 PtH/AMBj/kc5/ZXiv/oZof8AwAX/ABo/srxX/wBDND/4AL/jXR0Uci8/vYfW59o/+Ax/yOc/srxX /wBDND/4AL/jR/ZXiv8A6GaH/wAAF/xro6KORef3sPrc+0f/AAGP+Rzn9leK/wDoZof/AAAX/Gj+ yvFf/QzQ/wDgAv8AjXR0Uci8/vYfW59o/wDgMf8AI5z+yvFf/QzQ/wDgAv8AjR/ZXiv/AKGaH/wA X/Gujoo5F5/ew+tz7R/8Bj/kc5/ZXiv/AKGaH/wAX/Gj+yvFf/QzQ/8AgAv+NdHRRyLz+9h9bn2j /wCAx/yOc/srxX/0M0P/AIAL/jR/ZXiv/oZof/ABf8a6OijkXn97D63PtH/wGP8Akc5/ZXiv/oZo f/ABf8aP7K8V/wDQzQ/+AC/410dFHIvP72H1ufaP/gMf8jnP7K8V/wDQzQ/+AC/40f2V4r/6GaH/ AMAF/wAa6OijkXn97D63PtH/AMBj/kcyvh3WZ9TsbvUtbjukspfMWNbUJk4x1BrpqKKcYqOxlVrT q25radkl+QUUUVRiFFFFAH//2Q== --_004_991B70D8B4112A4699D5C00DDBBF878A671E2F1Cszxeml512mbschi_-- From nobody Fri Feb 6 00:42:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F881A19F8 for ; Fri, 6 Feb 2015 00:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20vyriP336wg for ; Fri, 6 Feb 2015 00:42:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8D17D1A0108 for ; Fri, 6 Feb 2015 00:42:31 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 96D541280996; Fri, 6 Feb 2015 09:42:30 +0100 (CET) Date: Fri, 06 Feb 2015 09:42:30 +0100 (CET) Message-Id: <20150206.094230.1927230089138171319.mbj@tail-f.com> To: rohitrranade@huawei.com From: Martin Bjorklund In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671E2F1C@szxeml512-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A671E2F1C@szxeml512-mbs.china.huawei.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Delimiter usage for Notifications RFC 5277, RFC 6242 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, 06 Feb 2015 08:42:34 -0000 Rohit R Ranade wrote: > Hi All, > > I have a scenario where many notifications get generated in my > device. When the client subscribes for these notifications, I do not > want to send him 1 notification per message. When you write "message" above, what do you mean? 1 notification = 1 NETCONF message = 1 XML document After every such NETCONF message, you MUST send the "]]>]]>" delimiter (if you follow 4742). > I want to maybe club the notifications I don't know what "club the notifications" mean. /martin From nobody Fri Feb 6 01:01: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 A384A1A19F8 for ; Fri, 6 Feb 2015 01:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O6fIStapppa1 for ; Fri, 6 Feb 2015 01:00:56 -0800 (PST) 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 CE8971A1A80 for ; Fri, 6 Feb 2015 01:00:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOY91586; Fri, 06 Feb 2015 09:00:54 +0000 (GMT) Received: from SZXEML429-HUB.china.huawei.com (10.82.67.184) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Feb 2015 09:00:53 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.141]) by SZXEML429-HUB.china.huawei.com ([10.82.67.184]) with mapi id 14.03.0158.001; Fri, 6 Feb 2015 17:00:24 +0800 From: Rohit R Ranade To: Martin Bjorklund Thread-Topic: [Netconf] Delimiter usage for Notifications RFC 5277, RFC 6242 Thread-Index: AdBB5wNUNVWaykz8RIyEAmdQ3uDjvf//fYwA//92vVA= Date: Fri, 6 Feb 2015 09:00:24 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A671E2F48@szxeml512-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A671E2F1C@szxeml512-mbs.china.huawei.com> <20150206.094230.1927230089138171319.mbj@tail-f.com> In-Reply-To: <20150206.094230.1927230089138171319.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.144.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Delimiter usage for Notifications RFC 5277, RFC 6242 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, 06 Feb 2015 09:00:58 -0000 Hi, By one message, I mean one SSH message. =3D=3D=3D=3D=3D> SSH message start 2014-08-27T01:21:18 abc 2 2 ]]>]]> 2014-08-27T01:21:18 abc 3 4 ]]>]]> =3D=3D=3D=3D=3D> SSH message End Clubbing of notifications refers to putting multiple notification messages = in one SSH message.=20 In RFC 6242, section 4.3 "Conceptually, the SSH Transport layer passes any data found in between the ]]>]]> characters to the Messages layer. " Does this mean that multiple delimiters can be found in a single SSH messag= e and NETCONF need to treat data between each ]]>]]> as a separate XML docu= ment and parse the same ? With Regards, Rohit From nobody Fri Feb 6 01:07: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 6FE681A03FF for ; Fri, 6 Feb 2015 01:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCAzHgtimEig for ; Fri, 6 Feb 2015 01:07:44 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFF51A0108 for ; Fri, 6 Feb 2015 01:07:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8D1891824; Fri, 6 Feb 2015 10:07:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3GLQ-QrBRKpL; Fri, 6 Feb 2015 10:07:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Feb 2015 10:07:43 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C394D20035; Fri, 6 Feb 2015 10:07:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nYbCIK6PFxu2; Fri, 6 Feb 2015 09:59:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB8E220036; Fri, 6 Feb 2015 10:07:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CACA1319C510; Fri, 6 Feb 2015 10:07:41 +0100 (CET) Date: Fri, 6 Feb 2015 10:07:41 +0100 From: Juergen Schoenwaelder To: Rohit R Ranade Message-ID: <20150206090741.GC67483@elstar.local> Mail-Followup-To: Rohit R Ranade , Martin Bjorklund , "netconf@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A671E2F1C@szxeml512-mbs.china.huawei.com> <20150206.094230.1927230089138171319.mbj@tail-f.com> <991B70D8B4112A4699D5C00DDBBF878A671E2F48@szxeml512-mbs.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671E2F48@szxeml512-mbs.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Delimiter usage for Notifications RFC 5277, RFC 6242 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, 06 Feb 2015 09:07:51 -0000 On Fri, Feb 06, 2015 at 09:00:24AM +0000, Rohit R Ranade wrote: > Hi, > > By one message, I mean one SSH message. > SSH ships data usually in SSH_MSG_CHANNEL_DATA messages, see RFC 4254. It is up to implementations how they map NETCONF messages into SSH_MSG_CHANNEL_DATA - the mapping can be pretty arbitrary (e.g., there is no requirement that NETCONF messages boundaries match SSH_MSG_CHANNEL_DATA message boundaries). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 6 01:29:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED371A1AA8 for ; Fri, 6 Feb 2015 01:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48MTuPTizEDK for ; Fri, 6 Feb 2015 01:28:56 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1AD1A03FF for ; Fri, 6 Feb 2015 01:28:56 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id E895012801A5; Fri, 6 Feb 2015 10:28:54 +0100 (CET) Date: Fri, 06 Feb 2015 10:28:54 +0100 (CET) Message-Id: <20150206.102854.2730586864134808.mbj@tail-f.com> To: rohitrranade@huawei.com From: Martin Bjorklund In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671E2F48@szxeml512-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A671E2F1C@szxeml512-mbs.china.huawei.com> <20150206.094230.1927230089138171319.mbj@tail-f.com> <991B70D8B4112A4699D5C00DDBBF878A671E2F48@szxeml512-mbs.china.huawei.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Delimiter usage for Notifications RFC 5277, RFC 6242 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, 06 Feb 2015 09:28:59 -0000 Rohit R Ranade wrote: > Hi, > > By one message, I mean one SSH message. Ok, this is fine. You don't have to send one NETCONF message in one SSH message. The NETCONF message might be huge and not even fit into one SSH packet, and it is perfectly fine to have multiple NETCONF messages in one SSH packet. (if you have that kind of control of the SSH packets...) > =====> SSH message start > > > > 2014-08-27T01:21:18 > > abc > > 2 > 2 > > > ]]>]]> > > > 2014-08-27T01:21:18 > > abc > > 3 > 4 > > > ]]>]]> > > =====> SSH message End > > Clubbing of notifications refers to putting multiple notification > messages in one SSH message. > In RFC 6242, section 4.3 "Conceptually, > the SSH Transport layer passes any data found in between the ]]>]]> > characters to the Messages layer. > " > > Does this mean that multiple delimiters can be found in a single SSH > message and NETCONF need to treat data between each ]]>]]> as a > separate XML document and parse the same ? Yes. /martin From nobody Fri Feb 6 14:42:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13C1A8792; Fri, 6 Feb 2015 14:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.054 X-Spam-Level: X-Spam-Status: No, score=-101.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRbFY_8NNWXV; Fri, 6 Feb 2015 14:42:35 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFC61A6F96; Fri, 6 Feb 2015 14:42:34 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> In-Reply-To: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> Date: Fri, 6 Feb 2015 17:42:21 -0500 Message-ID: <01d101d0425e$2d271740$877545c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01D2_01D04234.44563F60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIyIa+OW8V9HkmziikvEba5jtd8kpwgdpuw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, NETCONF , netmod@ietf.org Subject: [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 22:42:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D2_01D04234.44563F60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01D3_01D04234.44563F60" ------=_NextPart_001_01D3_01D04234.44563F60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IDR WG will hold an interim on 2/9/2015 that focuses on BGP Yang = modules. The agenda is below.=20 =20 Sue Hares and John Scudder=20 =20 --------- =20 Agenda: (75 minutes 10:00 - 11:15am) =20 1) A review of draft-zhdankin-idr-bgp-cfg-00 (Keyur Patel) [30 minutes]=20 =20 2) Overview of Policy Yang drafts in IETF (Sue Hares) [10 minutes]=20 =20 Other policy drafts to read=20 = http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00 = http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ = http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/ = http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/ = http://datatracker.ietf.org/doc/draft-hareskini-i2rs-pbr-info-model/ =20 3) Discussion comparing 2 BGP Yang modules [30 minutes]=20 draft-zhdankin-idr-bgp-cfg-00=20 =20 = https://github.com/YangModels/yang/tree/master/experimental/openconfig =20 =20 From: IDR Working Group [mailto:messenger@webex.com]=20 Sent: Friday, February 06, 2015 4:48 PM To: shares@ndzh.com Subject: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules =20 Hello,=20 IDR Working Group invites you to join this WebEx meeting.=20 =20 =20 =20 IDR Interim 2/9 - BGP Yang Modules=20 Monday, February 9, 2015=20 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 2 hrs=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 646 680 229=20 Meeting password: bgpyang =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 680 229 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. =20 =20 =20 Can't join the meeting? Contact = support.=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. =20 ------=_NextPart_001_01D3_01D04234.44563F60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

 

Sue Hares and John Scudder

 

---------

 

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

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

 

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

 

Other policy drafts to read

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

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

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

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

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

 

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

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

 

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

 

 

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

 

Hello,

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

 

 

 

IDR Interim 2/9 = - BGP Yang Modules =

Monday, February 9, 2015

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

 

 

 

Join = WebEx meeting =

 

Meeting number:

646 680 229

Meeting password:

bgpyang

 

 

 

Join by = phone

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

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

Access code: 646 680 229

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your = calendar.

 

 

 

Can't join the meeting? Contact support. =

 

 

 

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

 

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


 
Can't join the = meeting? Contact support. =  
 
IMPORTANT NOTICE: Please note that this WebEx service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the session.=0A= SUMMARY:IDR Interim 2/9 - BGP Yang Modules=0A= PRIORITY:5=0A= CLASS:PUBLIC=0A= BEGIN:VALARM=0A= TRIGGER:-PT5M=0A= ACTION:DISPLAY=0A= DESCRIPTION:Reminder=0A= END:VALARM=0A= END:VEVENT=0A= END:VCALENDAR=0A= ------=_NextPart_000_01D2_01D04234.44563F60-- From nobody Sat Feb 7 00:43:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2A91A1A6A; Sat, 7 Feb 2015 00:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyI_5sE2K77m; Sat, 7 Feb 2015 00:43:50 -0800 (PST) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187B21A8938; Sat, 7 Feb 2015 00:43:49 -0800 (PST) Received: from Macintosh-6.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id pLjl1p00G3vXPcr01LjnYu; Sat, 07 Feb 2015 09:43:47 +0100 Message-ID: <54D5D041.5070307@bwijnen.net> Date: Sat, 07 Feb 2015 09:43:45 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Susan Hares , idr wg References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> In-Reply-To: <01d101d0425e$2d271740$877545c0$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Rtg-yang-coord@ietf.org, NETCONF , netmod@ietf.org Subject: Re: [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 08:43:52 -0000 On 06/02/15 23:42, Susan Hares wrote: > Agenda: (75 minutes 10:00 - 11:15am) any specifics on time zone? we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we not? Bert From nobody Sat Feb 7 08:28:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86ED81A1AEA; Sat, 7 Feb 2015 08:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.055 X-Spam-Level: X-Spam-Status: No, score=-101.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez6SrlgQlGUc; Sat, 7 Feb 2015 08:28:49 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D51A0084; Sat, 7 Feb 2015 08:28:49 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Bert Wijnen \(IETF\)'" , "'idr wg'" References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> <54D5D041.5070307@bwijnen.net> In-Reply-To: Date: Sat, 7 Feb 2015 11:28:40 -0500 Message-ID: <003001d042f3$22c77ed0$68567c70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIyIa+OW8V9HkmziikvEba5jtd8kgJZ/j75Awex5hcBDXZmPJvuKZaQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, 'NETCONF' , netmod@ietf.org Subject: Re: [Netconf] [netmod] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 16:28:51 -0000 Bert: 10 - 11:30 am ET. My apologies for missing it. Sue -----Original Message----- From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, February 07, 2015 9:48 AM To: Bert Wijnen (IETF); Susan Hares; idr wg Cc: Rtg-yang-coord@ietf.org; NETCONF; netmod@ietf.org Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules Hi Bert, If you look at the WebEx, it is 10 AM EST (GMT - 5). Acee On 2/7/15, 2:43 AM, "Bert Wijnen (IETF)" wrote: >On 06/02/15 23:42, Susan Hares wrote: >> Agenda: (75 minutes 10:00 - 11:15am) >any specifics on time zone? > >we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we not? > >Bert > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Sat Feb 7 12:40: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 AA5051A8735; Sat, 7 Feb 2015 06:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.511 X-Spam-Level: X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCD7ssjIPJhn; Sat, 7 Feb 2015 06:48:24 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D331A8731; Sat, 7 Feb 2015 06:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=491; q=dns/txt; s=iport; t=1423320504; x=1424530104; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XgU3GPNTHQq2fv15ivCYBbae6zwDgQSLVRns6+wnaW0=; b=gTYaO3dvNq5JZofQxKmpVFbminotOHXTYMV8k691/zuE+yXy4dhX9BD+ /BrAi/ifPz7BJIFhcGmIIe+9hneNnrX/6L/x+M65uOw/+brHdYh5CLEfq RwC+easGARehyyIeXYqLr0cjv784/ZO2rO5Efq1Z3IdkrJyZKLIbRpTHu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A/BQCbJNZU/4ENJK1bgwZSWgTCcgqFJ0oCgQ9DAQEBAQEBfIQMAQEBBAEBATc0CxACAQgYHhAnCxwJAgQBDQWILQ3PPgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjEgBgy8HhCoBBI8biSyScCKCDyOBPG+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,535,1418083200"; d="scan'208";a="121483980" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 07 Feb 2015 14:48:23 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t17EmNW4024643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Feb 2015 14:48:23 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Sat, 7 Feb 2015 08:48:23 -0600 From: "Acee Lindem (acee)" To: "Bert Wijnen (IETF)" , Susan Hares , idr wg Thread-Topic: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules Thread-Index: AQHQQr8Dw4Yj9R/hCUyYBX1U1m3HoZzlRMMA Date: Sat, 7 Feb 2015 14:48:22 +0000 Message-ID: References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> <54D5D041.5070307@bwijnen.net> In-Reply-To: <54D5D041.5070307@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.185.175] Content-Type: text/plain; charset="us-ascii" Content-ID: <2609C62857BBC14196B149647A39CF38@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 07 Feb 2015 12:39:01 -0800 Cc: "Rtg-yang-coord@ietf.org" , NETCONF , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 14:48:25 -0000 Hi Bert, If you look at the WebEx, it is 10 AM EST (GMT - 5). Acee=20 On 2/7/15, 2:43 AM, "Bert Wijnen (IETF)" wrote: >On 06/02/15 23:42, Susan Hares wrote: >> Agenda: (75 minutes 10:00 - 11:15am) >any specifics on time zone? > >we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we not? > >Bert > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Feb 8 22:51: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 4D8811A0071 for ; Sun, 8 Feb 2015 22:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gnWvmbXP2j6 for ; Sun, 8 Feb 2015 22:50:31 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC161A006D for ; Sun, 8 Feb 2015 22:50:31 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id e89so6043558qgf.9 for ; Sun, 08 Feb 2015 22:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=2cSHKSgBylfgg8aDSH3XDZbEI9RT9nDfOIRzmyz6CHE=; b=mte6seFlLG+LL3BLMP7b43rN3ROyDg/j6JnpxAvDttwlBpQ6qThSn3VxwVQThjeyBP OxvW6L0Jb82H0JZTlg3y0k7WAEnnblqjaLmEaEoP6ETHn1Lup1w/CjdL3myTCFC9xqoB SaXIPo0hFfrc2yuXyzWwCsVXRnbACeajKxUi8LBvO5i5sjPMl+qVvcC7yOATbXtSe99w Mt5A1N4oq2lpd/Hu4rSpYKxgWU6eHCw1FJjVk+U594cP1sTUrznrGy0MEdteCtsqOtid +Rz85CnfCheiEX8EkfsXEenKoP4IWQhogssPow+v8otdaTkW9D97ztNHrUsM4X08n2TC RdPw== X-Received: by 10.229.212.6 with SMTP id gq6mr25025875qcb.26.1423464630463; Sun, 08 Feb 2015 22:50:30 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id c67sm10977671qgd.45.2015.02.08.22.50.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Feb 2015 22:50:29 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_3BF411C2-616B-4EE5-84DB-4326099E9099" Message-Id: Date: Sun, 8 Feb 2015 22:50:27 -0800 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Netconf] IPR Poll for draft-ietf-netconf-rfc5539bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 06:50:33 -0000 --Apple-Mail=_3BF411C2-616B-4EE5-84DB-4326099E9099 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG: This mail starts the IPR poll on draft-ietf-netconf-rfc5539bis-08.txt. Are you aware of any IPR that applies to = draft-ietf-netconf-rfc5539bis-08.txt? If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to = this email explicitly regardless of whether or not you are aware of any = relevant IPR. *The response needs to be sent to the NETCONF wg mailing list.* The = document will not advance to the next stage until a response has been received = from *each author and contributor*. If you are on the NETCONF WG email list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any = IPR that has not yet been disclosed in conformance with IETF rules. Thanks. Mahesh and Mehmet Chairs, NETCONF WG --Apple-Mail=_3BF411C2-616B-4EE5-84DB-4326099E9099 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii NETCONF WG:

This = mail starts the IPR poll on draft-ietf-netconf-rfc5539bis-08.txt.

Are you aware of any IPR that applies to = draft-ietf-netconf-rfc5539bis-08.txt?
If so, has this IPR = been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please = respond to this
email explicitly regardless of whether or = not you are aware of any relevant IPR.
*The response needs = to be sent to the NETCONF wg mailing list.* The document
will not advance to the next stage until a response has been = received from *each
author and contributor*.

If you are on the NETCONF WG email list but = are not listed as an author or
contributor, then please = explicitly respond only if you are aware of any IPR that
has= not yet been disclosed in conformance with IETF rules.

Thanks.

Mahesh and = Mehmet
Chairs, NETCONF WG





= --Apple-Mail=_3BF411C2-616B-4EE5-84DB-4326099E9099-- From nobody Sun Feb 8 23:14:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BA01A0071 for ; Sun, 8 Feb 2015 23:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXoPHUYAYRCo for ; Sun, 8 Feb 2015 23:14:52 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0448B1A0062 for ; Sun, 8 Feb 2015 23:14:52 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 583D8128F; Mon, 9 Feb 2015 08:14:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dOg-RMSokAqO; Mon, 9 Feb 2015 08:14:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 9 Feb 2015 08:14:49 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7C0E20037; Mon, 9 Feb 2015 08:14:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id k_jpdA70_8k6; Mon, 9 Feb 2015 08:14:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75FA320036; Mon, 9 Feb 2015 08:14:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A919C31D98E2; Mon, 9 Feb 2015 08:14:48 +0100 (CET) Date: Mon, 9 Feb 2015 08:14:48 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20150209071448.GA7106@elstar.local> Mail-Followup-To: Mahesh Jethanandani , Netconf References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] IPR Poll for draft-ietf-netconf-rfc5539bis-08.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: Mon, 09 Feb 2015 07:14:54 -0000 Hi, I am not aware of any IPR that applies to draft-ietf-netconf-rfc5539bis-08.txt /js On Sun, Feb 08, 2015 at 10:50:27PM -0800, Mahesh Jethanandani wrote: > NETCONF WG: > > This mail starts the IPR poll on draft-ietf-netconf-rfc5539bis-08.txt. > > Are you aware of any IPR that applies to draft-ietf-netconf-rfc5539bis-08.txt? > If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs > 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to this > email explicitly regardless of whether or not you are aware of any relevant IPR. > *The response needs to be sent to the NETCONF wg mailing list.* The document > will not advance to the next stage until a response has been received from *each > author and contributor*. > > If you are on the NETCONF WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any IPR that > has not yet been disclosed in conformance with IETF rules. > > Thanks. > > Mahesh and Mehmet > Chairs, NETCONF WG > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 9 00:31:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5B51A0091; Mon, 9 Feb 2015 00:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqiFFcAlpwkG; Mon, 9 Feb 2015 00:29:41 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBB91A007E; Mon, 9 Feb 2015 00:29:39 -0800 (PST) Received: from Macintosh-6.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id q8VY1p00E3vXPcr018VZeP; Mon, 09 Feb 2015 09:29:36 +0100 Message-ID: <54D86FEC.6030004@bwijnen.net> Date: Mon, 09 Feb 2015 09:29:32 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Susan Hares , "'Acee Lindem (acee)'" , 'idr wg' References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> <54D5D041.5070307@bwijnen.net> <003001d042f3$22c77ed0$68567c70$@ndzh.com> In-Reply-To: <003001d042f3$22c77ed0$68567c70$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Rtg-yang-coord@ietf.org, 'NETCONF' , netmod@ietf.org Subject: Re: [Netconf] [netmod] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 08:29:43 -0000 On 07/02/15 17:28, Susan Hares wrote: > Bert: > > 10 - 11:30 am ET. My apologies for missing it. No problem. That time is probably difficult or impossible for me. Bert > Sue > > -----Original Message----- > From: Acee Lindem (acee) [mailto:acee@cisco.com] > Sent: Saturday, February 07, 2015 9:48 AM > To: Bert Wijnen (IETF); Susan Hares; idr wg > Cc: Rtg-yang-coord@ietf.org; NETCONF; netmod@ietf.org > Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim > 2/9 - BGP Yang Modules > > Hi Bert, > > If you look at the WebEx, it is 10 AM EST (GMT - 5). > > Acee > > On 2/7/15, 2:43 AM, "Bert Wijnen (IETF)" wrote: > >> On 06/02/15 23:42, Susan Hares wrote: >>> Agenda: (75 minutes 10:00 - 11:15am) >> any specifics on time zone? >> >> we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we not? >> >> Bert >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > From nobody Mon Feb 9 09:25: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 1FAC81A1B59 for ; Mon, 9 Feb 2015 09:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHLyTq1lsMSw for ; Mon, 9 Feb 2015 09:01:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFE51A1B32 for ; Mon, 9 Feb 2015 09:01:29 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8BD8C1692; Mon, 9 Feb 2015 18:01:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id JaTW7Julm4iK; Mon, 9 Feb 2015 18:01:22 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 9 Feb 2015 18:01:24 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A07C020038; Mon, 9 Feb 2015 18:01:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ms9QAzwsBLZN; Mon, 9 Feb 2015 17:53:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A0A320036; Mon, 9 Feb 2015 18:01:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3E96831DFB1A; Mon, 9 Feb 2015 18:01:19 +0100 (CET) Date: Mon, 9 Feb 2015 18:01:19 +0100 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20150209170119.GB21527@elstar.local> Mail-Followup-To: "t. petch" , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <019601d0406b$16414900$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <019601d0406b$16414900$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 17:01:36 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, apparently the text is not clear enough since your interpretation seems to be somewhat incorrect. Does the attached rfcdiff resolve the issue? /js On Wed, Feb 04, 2015 at 11:09:38AM +0000, t. petch wrote: > I think that with the removal of the reference to server model, then the > steps in section 7 become hard to follow, almost incomprehensible - they > presume an information model which is not specified. I think that > Martin's comments revolved around this issue and that it is > insufficiently resolved. So I would rewrite section 7, not changing the > meaning one iota (well, if I have, then I think the section must be > incomprehensible:-) > > OLD > o The server maintains an ordered list of mappings of certificates > to NETCONF usernames. The username is derived by considering each > list entry in order. The fingerprint member of a list entry > determines whether the list entry is a match: > > 1. If the list entry's fingerprint value matches that of the > presented certificate, then consider the list entry as a > successful match. > > 2. If the list entry's fingerprint value matches that of a > locally held copy of a trusted CA certificate, and that CA > certificate was part of the CA certificate chain to the > presented certificate, then consider the list entry as a > successful match. > > o Once a matching list entry has been found, the mapping type > property of the list entry is used to determine how the username > associated with the certificate should be determined. Possible > mapping options are: > > A. The username is explicitly configured. > > B. The subjectAltName's rfc822Name is mapped to a username. > > C. The subjectAltName's dNSName is mapped to a username. > > D. The subjectAltName's iPAddress is mapped to a username. > > E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress is > mapped to a username. > > F. The certificate's CommonName is mapped to a username. > > o If it is impossible to determine a username from the list entry's > data combined with the data presented in the certificate, then > additional list entries MUST be searched looking for another > potential match. Similarily, if the username does not comply to > the NETCONF requirements on usernames [RFC6241] (i.e., the > username is not representable in XML), then additional list > entries MUST be searched looking for another potential match. If > there are no further list entries, the TLS session MUST be > terminated. > > NEW > > o The server maintains an ordered list, with each entry containing a > certificate fingerprint, a NETCONF username and, optionally, one or more > fields that may appear in the certificate, namely the rfc822Name, > dNSName or iPAddress as they appear in the subjectAltName field, or the > commonName [X520CommonName?] . > > The username is derived by considering each list entry in order. If > the list entry matches the presented certificate, then further checks > are carried out based on the list entry. If these result in an > acceptable username, then the search terminates. If the username is not > acceptable, then the search continues with the next list entry. If > there are no further list entries, the TLS session MUST be terminated. > > The test for a matching certificate is as follows. > > 1. If the fingerprint value of the list entry matches the > fingerprint of the > presented certificate, then consider the list entry as a > successful match. > > 2. If the fingerprint value of the list entry matches that of a > locally held copy of a trusted CA certificate, and that CA > certificate was part of the CA certificate chain to the > presented certificate, then consider the list entry as a > successful match. > > Once a matching list entry has been found, the list entry is considered > further. If the username does not comply to the NETCONF requirements on > usernames [RFC6241] (i.e., the username is not representable in XML), > then the username is not acceptable and list entries MUST be searched > looking for another certificate match. > > A. If the list entry contains just a compliant username, then > that username is used. > > B. If the list entry contains just an rfc822Name which matches > that in the matched certificate, then the username from the list entry > is used.. > > C. If the list entry contains just a dNSName which matches that > in the matched certificate, then the username from the list entry is > used.. > > D. If the list entry contains just an iPAddress which matches > that in the matched certificate, then the username from the list entry > is used.. > . > E. If the list entry contains more than one of rfc822Name, > dNSName and iPAddress, and one or more of them match the corresponding > fields in the matched certificate, then the username from the list entry > is used.. > > [What happens if e.g. the dNSName matches but the rfc822Name does not? > Needs clarifying IMO] > > F. If the commonName matches that in the matched certificate, > then the username from the list entry is used.. > > G. If none of the steps above yield an acceptable username, then > additional list entries MUST be searched looking for a further > certificate match. > > Tom Petch > > ----- Original Message ----- > From: "Ersue, Mehmet (NSN - DE/Munich)" > To: > Sent: Friday, January 30, 2015 2:17 PM > Subject: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 > > > > Dear NETCONF WG, > > > > we think the WGLC of the draft-ietf-netconf-rfc5539bis was successful > > with useful comments and discussion. Based on the WGLC result Juergen > > provided draft-ietf-netconf-rfc5539bis-08. > > > > See http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08 > > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-08.txt > > > > Please look at v08 of the draft and let the co-chairs know by February > 4, > > 2015 EOB PT, whether you have any objections to starting the > publications > > process and asking our AD Benoit Claise to do his review. > > > > Best Regards, > > Mehmet and Mahesh > > > > > > -----Original Message----- > > From: ext Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, January 27, 2015 8:24 AM > > To: Ersue, Mehmet (NSN - DE/Munich) > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] WG Last Call for > draft-ietf-netconf-rfc5539bis-07 > > > > On Mon, Jan 05, 2015 at 08:46:09PM +0000, Ersue, Mehmet (NSN - > DE/Munich) wrote: > > > Dear NETCONF Members, > > > > > > we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. > > > > > > The document can be found at: > > > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 > > > > > > Please review and send your comments to the WG mailing list by > January 19, 2015 EOB PT. > > > > > > > Mehmet and Mahesh, > > > > I have posted draft-ietf-netconf-rfc5539bis-08 which I believe > > addresses the WG last call comments. Please check and if you agree, > > please produce a document writeup and move the I-D over to the IESG. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > 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 --dDRMvlgZJXvWKvBx Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-netconf-rfc5539bis-09-from-8.diff.html" Diff: draft-ietf-netconf-rfc5539bis-08.txt - draft-ietf-netconf-rfc5539bis-09.txt
 draft-ietf-netconf-rfc5539bis-08.txt   draft-ietf-netconf-rfc5539bis-09.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: July 31, 2015 J. Schoenwaelder Expires: August 13, 2015 J. Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
January 27, 2015 February 9, 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-08 draft-ietf-netconf-rfc5539bis-09
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 July 31, 2015. This Internet-Draft will expire on August 13, 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . 4
6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4 6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4
7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4 7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4
8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 8 Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 8
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 8 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9
B.1. draft-ietf-netconf-rfc5539bis-07 . . . . . . . . . . . . 8 B.1. draft-ietf-netconf-rfc5539bis-07 . . . . . . . . . . . . 9
B.2. draft-ietf-netconf-rfc5539bis-06 . . . . . . . . . . . . 9 B.2. draft-ietf-netconf-rfc5539bis-06 . . . . . . . . . . . . 9
B.3. draft-ietf-netconf-rfc5539bis-05 . . . . . . . . . . . . 9 B.3. draft-ietf-netconf-rfc5539bis-05 . . . . . . . . . . . . 9
B.4. draft-ietf-netconf-rfc5539bis-04 . . . . . . . . . . . . 9 B.4. draft-ietf-netconf-rfc5539bis-04 . . . . . . . . . . . . 9
B.5. draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . 9 B.5. draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . 9
B.6. draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . 9 B.6. draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . 10
B.7. draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . 10 B.7. draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 4, line 33 skipping to change at page 4, line 33
ensure that the incoming request to establish a NETCONF session is ensure that the incoming request to establish a NETCONF session is
legitimate before the NETCONF session is started. legitimate before the NETCONF session is started.
The NETCONF protocol [RFC6241] requires that the transport protocol's The NETCONF protocol [RFC6241] requires that the transport protocol's
authentication process results in an authenticated NETCONF client authentication process results in an authenticated NETCONF client
identity whose permissions are known to the server. The identity whose permissions are known to the server. The
authenticated identity of a client is commonly referred to as the authenticated identity of a client is commonly referred to as the
NETCONF username. The following algorithm is used by the NETCONF NETCONF username. The following algorithm is used by the NETCONF
server to derive a NETCONF username from a certificate: server to derive a NETCONF username from a certificate:
o The server maintains an ordered list of mappings of certificates (a) The server maintains an ordered list of mappings of certificates
to NETCONF usernames. The username is derived by considering each to NETCONF usernames. Each list entry contains
list entry in order. The fingerprint member of a list entry
determines whether the list entry is a match:
1. If the list entry's fingerprint value matches that of the * a certificate fingerprint (used for matching the presented
presented certificate, then consider the list entry as a certificate),
successful match.
* a mapping type (indicates how the NETCONF username is derived
from the certificate), and
* optional auxiliary data (used to carry a NETCONF username if
the mapping type indicates the user name is explicitely
configured).
(b) The NETCONF username is derived by considering each list entry
in order. The fingerprint member of the current list entry
determines whether the current list entry is a match:
1. If the list entry's fingerprint value matches the
fingerprint of the presented certificate, then consider the
list entry as a successful match.
2. If the list entry's fingerprint value matches that of a 2. If the list entry's fingerprint value matches that of a
locally held copy of a trusted CA certificate, and that CA locally held copy of a trusted CA certificate, and that CA
certificate was part of the CA certificate chain to the certificate was part of the CA certificate chain to the
presented certificate, then consider the list entry as a presented certificate, then consider the list entry as a
successful match. successful match.
o Once a matching list entry has been found, the mapping type (c) Once a matching list entry has been found, the mapping type
property of the list entry is used to determine how the username property of the current list entry is used to determine how the
associated with the certificate should be determined. Possible username associated with the certificate should be determined.
mapping options are: Possible mapping options are:
A. The username is explicitly configured. A. The username is taken from the auxiliary data of the current
list entry. This means the username is explicitely
configured (map type 'specified').
B. The subjectAltName's rfc822Name is mapped to a username. B. The subjectAltName's rfc822Name field is mapped to the
username (map type 'san-rfc822-name').
C. The subjectAltName's dNSName is mapped to a username. C. The subjectAltName's dNSName is mapped to the username (map
type 'san-dns-name').
D. The subjectAltName's iPAddress is mapped to a username. D. The subjectAltName's iPAddress is mapped to the username
(map type 'san-ip-address').
E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress is E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress
mapped to a username. is mapped to the username (map type 'san-any'). The first
matching subjectAltName value found in the certificate of
the above types MUST be used when deriving the name.
F. The certificate's CommonName is mapped to a username. F. The certificate's CommonName is mapped to the username (map
type 'common-name').
o If it is impossible to determine a username from the list entry's (d) If it is impossible to determine a username from the list
data combined with the data presented in the certificate, then entry's data combined with the data presented in the
additional list entries MUST be searched looking for another certificate, then additional list entries MUST be searched
potential match. Similarily, if the username does not comply to looking for another potential match. Similarily, if the
the NETCONF requirements on usernames [RFC6241] (i.e., the username does not comply to the NETCONF requirements on
username is not representable in XML), then additional list usernames [RFC6241] (i.e., the username is not representable in
entries MUST be searched looking for another potential match. If XML), then additional list entries MUST be searched looking for
there are no further list entries, the TLS session MUST be another potential match. If there are no further list entries,
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.
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
 End of changes. 17 change blocks. 
39 lines changed or deleted 59 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/
--dDRMvlgZJXvWKvBx-- From nobody Tue Feb 10 10:07: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 732941A02F1; Tue, 10 Feb 2015 10:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w95Lo9od8gYo; Tue, 10 Feb 2015 10:07:26 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F651A06FD; Tue, 10 Feb 2015 10:07:26 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.75.20; Tue, 10 Feb 2015 18:07:08 +0000 Message-ID: <032701d0455c$27b622a0$4001a8c0@gateway.2wire.net> From: t.petch To: "Ken Gray (kegray)" References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> <54D5D041.5070307@bwijnen.net> <003001d042f3$22c77ed0$68567c70$@ndzh.com>, <54D86FEC.6030004@bwijnen.net> Date: Tue, 10 Feb 2015 18:03:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR03CA0014.eurprd03.prod.outlook.com (25.160.39.152) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB063; X-Forefront-PRVS: 048396AFA0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(24454002)(497574002)(377424004)(39224004)(479174004)(377454003)(44736004)(50466002)(66066001)(50226001)(122386002)(81686999)(19580405001)(86362001)(92566002)(40100003)(76176999)(47776003)(50986999)(23756003)(14496001)(81816999)(42186005)(33646002)(46102003)(77096005)(110136001)(87976001)(15975445007)(1720100001)(62236002)(44716002)(19580395003)(77156002)(230783001)(93886004)(116806002)(62966003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2015 18:07:08.2079 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB063 Archived-At: Cc: Rtg-yang-coord@ietf.org, idr wg , NETCONF , netmod@ietf.org Subject: Re: [Netconf] [Rtg-yang-coord] [netmod] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:07:29 -0000 You could try http://www.ietf.org/proceedings/interim/2015/02/09/idr/minutes/minutes-i nterim-2015-idr-3 On the other hand, nothing has yet appeared for the meeting scheduled for 2015-1-12:-( Tom Petch ----- Original Message ----- From: "Ken Gray (kegray)" To: "Bert Wijnen (IETF)" Cc: ; "idr wg" ; ; "NETCONF" ; "Acee Lindem (acee)" ; "Susan Hares" Sent: Tuesday, February 10, 2015 4:03 PM Subject: Re: [Rtg-yang-coord] [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules > Recorded by chance? > > Sent from my iPhone > > > On Feb 9, 2015, at 1:03 PM, "Bert Wijnen (IETF)" wrote: > > > >> On 07/02/15 17:28, Susan Hares wrote: > >> Bert: > >> > >> 10 - 11:30 am ET. My apologies for missing it. > > > > No problem. That time is probably difficult or impossible for me. > > > > Bert > >> Sue > >> > >> -----Original Message----- > >> From: Acee Lindem (acee) [mailto:acee@cisco.com] > >> Sent: Saturday, February 07, 2015 9:48 AM > >> To: Bert Wijnen (IETF); Susan Hares; idr wg > >> Cc: Rtg-yang-coord@ietf.org; NETCONF; netmod@ietf.org > >> Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim > >> 2/9 - BGP Yang Modules > >> > >> Hi Bert, > >> > >> If you look at the WebEx, it is 10 AM EST (GMT - 5). > >> > >> Acee > >> > >>> On 2/7/15, 2:43 AM, "Bert Wijnen (IETF)" wrote: > >>> > >>>> On 06/02/15 23:42, Susan Hares wrote: > >>>> Agenda: (75 minutes 10:00 - 11:15am) > >>> any specifics on time zone? > >>> > >>> we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we not? > >>> > >>> Bert > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Feb 11 04:21: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 B4B891A885E for ; Wed, 11 Feb 2015 04:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 OgCXGWSzCEmY for ; Wed, 11 Feb 2015 04:20:54 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025F61A8856 for ; Wed, 11 Feb 2015 04:20:53 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.1.81.19; Wed, 11 Feb 2015 12:19:04 +0000 Message-ID: <01b101d045f4$b19c6d60$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <019601d0406b$16414900$4001a8c0@gateway.2wire.net> <20150209170119.GB21527@elstar.local> Date: Wed, 11 Feb 2015 12:15:37 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR03CA0016.eurprd03.prod.outlook.com (25.160.39.154) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) Authentication-Results: jacobs-university.de; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMSPR07MB051; X-Forefront-PRVS: 0484063412 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(51704005)(42186005)(61296003)(23756003)(116806002)(230783001)(92566002)(50466002)(77156002)(1720100001)(1456003)(81686999)(50986999)(81816999)(76176999)(77096005)(19580405001)(62966003)(15975445007)(33646002)(19580395003)(66066001)(110136001)(47776003)(87976001)(44716002)(50226001)(46102003)(44736004)(86362001)(122386002)(40100003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2015 12:19:04.3120 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB051 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:20:59 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Sent: Monday, February 09, 2015 5:01 PM > Hi, > > apparently the text is not clear enough since your interpretation > seems to be somewhat incorrect. Does the attached rfcdiff resolve the > issue? Yes, my interpretation was incorrect and this is clearer but I am still left uncertain over steps A to F when they say e.g. D. The subjectAltName's iPAddress is mapped to the username (map type 'san-ip-address'). How is it mapped? I assume that an iPAddress cannot be a username per se(!) so I imagine that there needs to be a data structure with a list of iPAddress and corresponding username. Since -08 only mentioned the one data structure, I rolled everything into that data structure. Your rewording leads me to create a second data structure mapping the various fields from the certificate to a username. If so, I think that this is worth a mention under a). A minor comment; I would prefer a consistent identifier for 'map type', such as 'map type' - currently, you have 'mapping type', 'mapping type property' and 'map type', Tom Petch > > /js > > On Wed, Feb 04, 2015 at 11:09:38AM +0000, t. petch wrote: > > I think that with the removal of the reference to server model, then the > > steps in section 7 become hard to follow, almost incomprehensible - they > > presume an information model which is not specified. I think that > > Martin's comments revolved around this issue and that it is > > insufficiently resolved. So I would rewrite section 7, not changing the > > meaning one iota (well, if I have, then I think the section must be > > incomprehensible:-) > > > > OLD > > o The server maintains an ordered list of mappings of certificates > > to NETCONF usernames. The username is derived by considering each > > list entry in order. The fingerprint member of a list entry > > determines whether the list entry is a match: > > > > 1. If the list entry's fingerprint value matches that of the > > presented certificate, then consider the list entry as a > > successful match. > > > > 2. If the list entry's fingerprint value matches that of a > > locally held copy of a trusted CA certificate, and that CA > > certificate was part of the CA certificate chain to the > > presented certificate, then consider the list entry as a > > successful match. > > > > o Once a matching list entry has been found, the mapping type > > property of the list entry is used to determine how the username > > associated with the certificate should be determined. Possible > > mapping options are: > > > > A. The username is explicitly configured. > > > > B. The subjectAltName's rfc822Name is mapped to a username. > > > > C. The subjectAltName's dNSName is mapped to a username. > > > > D. The subjectAltName's iPAddress is mapped to a username. > > > > E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress is > > mapped to a username. > > > > F. The certificate's CommonName is mapped to a username. > > > > o If it is impossible to determine a username from the list entry's > > data combined with the data presented in the certificate, then > > additional list entries MUST be searched looking for another > > potential match. Similarily, if the username does not comply to > > the NETCONF requirements on usernames [RFC6241] (i.e., the > > username is not representable in XML), then additional list > > entries MUST be searched looking for another potential match. If > > there are no further list entries, the TLS session MUST be > > terminated. > > > > NEW > > > > o The server maintains an ordered list, with each entry containing a > > certificate fingerprint, a NETCONF username and, optionally, one or more > > fields that may appear in the certificate, namely the rfc822Name, > > dNSName or iPAddress as they appear in the subjectAltName field, or the > > commonName [X520CommonName?] . > > > > The username is derived by considering each list entry in order. If > > the list entry matches the presented certificate, then further checks > > are carried out based on the list entry. If these result in an > > acceptable username, then the search terminates. If the username is not > > acceptable, then the search continues with the next list entry. If > > there are no further list entries, the TLS session MUST be terminated. > > > > The test for a matching certificate is as follows. > > > > 1. If the fingerprint value of the list entry matches the > > fingerprint of the > > presented certificate, then consider the list entry as a > > successful match. > > > > 2. If the fingerprint value of the list entry matches that of a > > locally held copy of a trusted CA certificate, and that CA > > certificate was part of the CA certificate chain to the > > presented certificate, then consider the list entry as a > > successful match. > > > > Once a matching list entry has been found, the list entry is considered > > further. If the username does not comply to the NETCONF requirements on > > usernames [RFC6241] (i.e., the username is not representable in XML), > > then the username is not acceptable and list entries MUST be searched > > looking for another certificate match. > > > > A. If the list entry contains just a compliant username, then > > that username is used. > > > > B. If the list entry contains just an rfc822Name which matches > > that in the matched certificate, then the username from the list entry > > is used.. > > > > C. If the list entry contains just a dNSName which matches that > > in the matched certificate, then the username from the list entry is > > used.. > > > > D. If the list entry contains just an iPAddress which matches > > that in the matched certificate, then the username from the list entry > > is used.. > > . > > E. If the list entry contains more than one of rfc822Name, > > dNSName and iPAddress, and one or more of them match the corresponding > > fields in the matched certificate, then the username from the list entry > > is used.. > > > > [What happens if e.g. the dNSName matches but the rfc822Name does not? > > Needs clarifying IMO] > > > > F. If the commonName matches that in the matched certificate, > > then the username from the list entry is used.. > > > > G. If none of the steps above yield an acceptable username, then > > additional list entries MUST be searched looking for a further > > certificate match. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Ersue, Mehmet (NSN - DE/Munich)" > > To: > > Sent: Friday, January 30, 2015 2:17 PM > > Subject: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 > > > > > > > Dear NETCONF WG, > > > > > > we think the WGLC of the draft-ietf-netconf-rfc5539bis was successful > > > with useful comments and discussion. Based on the WGLC result Juergen > > > provided draft-ietf-netconf-rfc5539bis-08. > > > > > > See http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08 > > > > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-08.txt > > > > > > Please look at v08 of the draft and let the co-chairs know by February > > 4, > > > 2015 EOB PT, whether you have any objections to starting the > > publications > > > process and asking our AD Benoit Claise to do his review. > > > > > > Best Regards, > > > Mehmet and Mahesh > > > > > > > > > -----Original Message----- > > > From: ext Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Tuesday, January 27, 2015 8:24 AM > > > To: Ersue, Mehmet (NSN - DE/Munich) > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] WG Last Call for > > draft-ietf-netconf-rfc5539bis-07 > > > > > > On Mon, Jan 05, 2015 at 08:46:09PM +0000, Ersue, Mehmet (NSN - > > DE/Munich) wrote: > > > > Dear NETCONF Members, > > > > > > > > we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. > > > > > > > > The document can be found at: > > > > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 > > > > > > > > Please review and send your comments to the WG mailing list by > > January 19, 2015 EOB PT. > > > > > > > > > > Mehmet and Mahesh, > > > > > > I have posted draft-ietf-netconf-rfc5539bis-08 which I believe > > > addresses the WG last call comments. Please check and if you agree, > > > please produce a document writeup and move the I-D over to the IESG. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > 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 Wed Feb 11 04:55:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F196F1A888C for ; Wed, 11 Feb 2015 04:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 P-7kRcjEq2_2 for ; Wed, 11 Feb 2015 04:55:44 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626381A887F for ; Wed, 11 Feb 2015 04:55:44 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.1.81.19; Wed, 11 Feb 2015 12:27:14 +0000 Message-ID: <01b401d045f5$d5a1d000$4001a8c0@gateway.2wire.net> From: t.petch To: Mahesh Jethanandani , Netconf References: Date: Wed, 11 Feb 2015 12:24:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR03CA0012.eurprd03.prod.outlook.com (25.160.39.150) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMSPR07MB052; X-Forefront-PRVS: 0484063412 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(42186005)(87976001)(19580405001)(61296003)(66066001)(44716002)(62236002)(1556002)(230783001)(77096005)(40100003)(116806002)(50466002)(86362001)(47776003)(122386002)(19580395003)(50226001)(44736004)(15975445007)(92566002)(77156002)(62966003)(46102003)(33646002)(14496001)(76176999)(81686999)(1456003)(84392001)(50986999)(81816999)(107886001)(23756003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2015 12:27:14.3788 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB052 Archived-At: Subject: Re: [Netconf] IPR Poll for draft-ietf-netconf-rfc5539bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:55:48 -0000 I don't know if I have contributed anything to this I-D or not - it has changed so much over the years - but if I have, I know of no IPR relating to my contributions. Tom Petch ----- Original Message ----- From: "Mahesh Jethanandani" To: "Netconf" Sent: Monday, February 09, 2015 6:50 AM NETCONF WG: This mail starts the IPR poll on draft-ietf-netconf-rfc5539bis-08.txt. Are you aware of any IPR that applies to draft-ietf-netconf-rfc5539bis-08.txt? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email explicitly regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the NETCONF wg mailing list.* The document will not advance to the next stage until a response has been received from *each author and contributor*. If you are on the NETCONF WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks. Mahesh and Mehmet Chairs, NETCONF WG ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Wed Feb 11 09:57:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884981A0AC8 for ; Wed, 11 Feb 2015 09:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWqmgEioo7gG for ; Wed, 11 Feb 2015 09:57:47 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47BC1A1A6B for ; Wed, 11 Feb 2015 09:57:46 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 11 Feb 2015 17:57:23 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.134]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.134]) with mapi id 15.01.0081.018; Wed, 11 Feb 2015 17:57:23 +0000 From: Kent Watsen To: t.petch , Mahesh Jethanandani , Netconf Thread-Topic: [Netconf] IPR Poll for draft-ietf-netconf-rfc5539bis-08.txt Thread-Index: AQHQRDS4dMwRRo0UeEKhOa9LtBtj7Jzra7w2gAAAZQA= Date: Wed, 11 Feb 2015 17:57:22 +0000 Message-ID: References: <01b401d045f5$d5a1d000$4001a8c0@gateway.2wire.net> In-Reply-To: <01b401d045f5$d5a1d000$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.10] authentication-results: btconnect.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(479174004)(24454002)(51704005)(377454003)(122556002)(83506001)(77156002)(230783001)(40100003)(50986999)(102836002)(62966003)(36756003)(66066001)(46102003)(86362001)(87936001)(107886001)(106116001)(92566002)(19580405001)(99286002)(19580395003)(2950100001)(15975445007)(76176999)(2656002)(54356999)(2900100001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <4119DB465BBCBF40AE5FF5413711E7CA@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2015 17:57:22.6181 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: Re: [Netconf] IPR Poll for draft-ietf-netconf-rfc5539bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:57:49 -0000 I am unaware of any IPR related to this draft. Kent On 2/11/15, 7:24 AM, "t.petch" wrote: >I don't know if I have contributed anything to this I-D or not - it has >changed so much over the years - but if I have, I know of no IPR >relating to my contributions. > >Tom Petch > > >----- Original Message ----- >From: "Mahesh Jethanandani" >To: "Netconf" >Sent: Monday, February 09, 2015 6:50 AM > >NETCONF WG: > >This mail starts the IPR poll on draft-ietf-netconf-rfc5539bis-08.txt. > >Are you aware of any IPR that applies to >draft-ietf-netconf-rfc5539bis-08.txt? >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs >3979, 4879, 3669 and 5378 for more details). > >If you are listed as a document author or contributor please respond to >this >email explicitly regardless of whether or not you are aware of any >relevant IPR. >*The response needs to be sent to the NETCONF wg mailing list.* The >document >will not advance to the next stage until a response has been received >from *each >author and contributor*. > >If you are on the NETCONF WG email list but are not listed as an author >or >contributor, then please explicitly respond only if you are aware of any >IPR that >has not yet been disclosed in conformance with IETF rules. > >Thanks. > >Mahesh and Mehmet >Chairs, NETCONF WG > > > > > > > > >------------------------------------------------------------------------ >-------- > > >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Feb 11 12:25: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 16D5C1A1EEF for ; Wed, 11 Feb 2015 12:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M31VldkFSX-6 for ; Wed, 11 Feb 2015 12:24:54 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F21A0250 for ; Wed, 11 Feb 2015 12:24:54 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA24317 for ; Wed, 11 Feb 2015 15:24:52 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t1BKOrhE063356 for ; Wed, 11 Feb 2015 15:24:53 -0500 (EST) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t1BKOrsv063355; Wed, 11 Feb 2015 15:24:53 -0500 (EST) (envelope-from luchuk) Date: Wed, 11 Feb 2015 15:24:53 -0500 (EST) From: Alan Luchuk Message-Id: <201502112024.t1BKOrsv063355@mainfs.snmp.com> To: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Subject: Re: [Netconf] IPR Poll for draft-ietf-netconf-rfc5539bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 20:25:00 -0000 Hello, I am unaware of any IPR related to this draft. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From nobody Wed Feb 11 14:55: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 56DB11A1B9E; Wed, 11 Feb 2015 14:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpdzwUz8ud9b; Wed, 11 Feb 2015 14:55:45 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5361A1A1E; Wed, 11 Feb 2015 14:55:44 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" References: <1716926046.1975221423694292688.JavaMail.nobody@rva2rmd002.webex.com> In-Reply-To: <1716926046.1975221423694292688.JavaMail.nobody@rva2rmd002.webex.com> Date: Wed, 11 Feb 2015 17:55:35 -0500 Message-ID: <074c01d0464d$d92d11a0$8b8734e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_074D_01D04623.F057F400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHJ57GBwTjsxCJFcI4UebhxZCloJpz4yCiQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, "'Ken Gray \(kegray\)'" , netmod@ietf.org, NETCONF , "John G. Scudder" Subject: [Netconf] FW: WebEx recording is available for viewing: IDR Interim 2/9 - BGP Yang Modules-20150209 1500-1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 22:55:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_074D_01D04623.F057F400 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IDR Working Group wants to share this WebEx recording with you.=20 IDR Interim 2/9 - BGP Yang Modules-20150209 1500-1=20 Monday, February 9, 2015=20 11:17 am | Eastern Standard Time (New York, GMT-05:00)=20 PLAY RECORDING (1 hr 8 min)=20 https://ietf.webex.com/ietf/ldr.php?RCID=3Ddad5cf872d4469f95ad00b0330f8e9= d8=20 This is the recording of the discussion of the BGP Yang modules. =20 = draft-zhdankin-idr-bgp-cfg-00 = draft-shaikh-idr-bgp-model-00=20 =20 Sue Hares=20 ------=_NextPart_000_074D_01D04623.F057F400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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


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


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

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

draft-zhdankin-idr-bgp-cfg-00

draft-shaikh-idr-bgp-model-00

 

Sue Hares

------=_NextPart_000_074D_01D04623.F057F400-- From nobody Wed Feb 11 23:43:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6471A911D for ; Wed, 11 Feb 2015 23:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sj0LTLisvtw for ; Wed, 11 Feb 2015 23:42:56 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABB61A0399 for ; Wed, 11 Feb 2015 23:42:56 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0809019DF; Thu, 12 Feb 2015 08:42:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lpSBsrWDM7WY; Thu, 12 Feb 2015 08:42:32 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 12 Feb 2015 08:42:50 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71EF720037; Thu, 12 Feb 2015 08:42:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KUKeDj5KjN_q; Thu, 12 Feb 2015 08:42:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95F4D20036; Thu, 12 Feb 2015 08:42:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BAE963202C4F; Thu, 12 Feb 2015 08:42:40 +0100 (CET) Date: Thu, 12 Feb 2015 08:42:40 +0100 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20150212074240.GC9173@elstar.local> Mail-Followup-To: "t. petch" , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <019601d0406b$16414900$4001a8c0@gateway.2wire.net> <20150209170119.GB21527@elstar.local> <01b101d045f4$b19c6d60$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <01b101d045f4$b19c6d60$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 07:43:06 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, here is another attempt, incorporating more text from the RFCs that originally defined this algorithm. /js On Wed, Feb 11, 2015 at 12:15:37PM +0000, t. petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "t. petch" > Sent: Monday, February 09, 2015 5:01 PM > > > Hi, > > > > apparently the text is not clear enough since your interpretation > > seems to be somewhat incorrect. Does the attached rfcdiff resolve the > > issue? > > Yes, my interpretation was incorrect and this is clearer but I am still > left uncertain over steps A to F when they say e.g. > > D. The subjectAltName's iPAddress is mapped to the username > (map type 'san-ip-address'). > > How is it mapped? I assume that an iPAddress cannot be a username per > se(!) so I imagine that there needs to be a data structure with a list > of iPAddress and corresponding username. Since -08 only mentioned the > one data structure, I rolled everything into that data structure. Your > rewording leads me to create a second data structure mapping the various > fields from the certificate to a username. If so, I think that this is > worth a mention under a). > > A minor comment; I would prefer a consistent identifier for 'map type', > such as 'map type' - currently, you have 'mapping type', 'mapping type > property' and 'map type', > > Tom Petch > > > > > /js > > > > On Wed, Feb 04, 2015 at 11:09:38AM +0000, t. petch wrote: > > > I think that with the removal of the reference to server model, then > the > > > steps in section 7 become hard to follow, almost incomprehensible - > they > > > presume an information model which is not specified. I think that > > > Martin's comments revolved around this issue and that it is > > > insufficiently resolved. So I would rewrite section 7, not changing > the > > > meaning one iota (well, if I have, then I think the section must be > > > incomprehensible:-) > > > > > > OLD > > > o The server maintains an ordered list of mappings of certificates > > > to NETCONF usernames. The username is derived by considering > each > > > list entry in order. The fingerprint member of a list entry > > > determines whether the list entry is a match: > > > > > > 1. If the list entry's fingerprint value matches that of the > > > presented certificate, then consider the list entry as a > > > successful match. > > > > > > 2. If the list entry's fingerprint value matches that of a > > > locally held copy of a trusted CA certificate, and that CA > > > certificate was part of the CA certificate chain to the > > > presented certificate, then consider the list entry as a > > > successful match. > > > > > > o Once a matching list entry has been found, the mapping type > > > property of the list entry is used to determine how the > username > > > associated with the certificate should be determined. > Possible > > > mapping options are: > > > > > > A. The username is explicitly configured. > > > > > > B. The subjectAltName's rfc822Name is mapped to a username. > > > > > > C. The subjectAltName's dNSName is mapped to a username. > > > > > > D. The subjectAltName's iPAddress is mapped to a username. > > > > > > E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress > is > > > mapped to a username. > > > > > > F. The certificate's CommonName is mapped to a username. > > > > > > o If it is impossible to determine a username from the list > entry's > > > data combined with the data presented in the certificate, then > > > additional list entries MUST be searched looking for another > > > potential match. Similarily, if the username does not comply > to > > > the NETCONF requirements on usernames [RFC6241] (i.e., the > > > username is not representable in XML), then additional list > > > entries MUST be searched looking for another potential match. > If > > > there are no further list entries, the TLS session MUST be > > > terminated. > > > > > > NEW > > > > > > o The server maintains an ordered list, with each entry containing > a > > > certificate fingerprint, a NETCONF username and, optionally, one or > more > > > fields that may appear in the certificate, namely the rfc822Name, > > > dNSName or iPAddress as they appear in the subjectAltName field, or > the > > > commonName [X520CommonName?] . > > > > > > The username is derived by considering each list entry in order. > If > > > the list entry matches the presented certificate, then further > checks > > > are carried out based on the list entry. If these result in an > > > acceptable username, then the search terminates. If the username is > not > > > acceptable, then the search continues with the next list entry. If > > > there are no further list entries, the TLS session MUST be > terminated. > > > > > > The test for a matching certificate is as follows. > > > > > > 1. If the fingerprint value of the list entry matches the > > > fingerprint of the > > > presented certificate, then consider the list entry as a > > > successful match. > > > > > > 2. If the fingerprint value of the list entry matches that of > a > > > locally held copy of a trusted CA certificate, and that CA > > > certificate was part of the CA certificate chain to the > > > presented certificate, then consider the list entry as a > > > successful match. > > > > > > Once a matching list entry has been found, the list entry is > considered > > > further. If the username does not comply to the NETCONF > requirements on > > > usernames [RFC6241] (i.e., the username is not representable in > XML), > > > then the username is not acceptable and list entries MUST be > searched > > > looking for another certificate match. > > > > > > A. If the list entry contains just a compliant username, then > > > that username is used. > > > > > > B. If the list entry contains just an rfc822Name which > matches > > > that in the matched certificate, then the username from the list > entry > > > is used.. > > > > > > C. If the list entry contains just a dNSName which matches > that > > > in the matched certificate, then the username from the list entry is > > > used.. > > > > > > D. If the list entry contains just an iPAddress which matches > > > that in the matched certificate, then the username from the list > entry > > > is used.. > > > . > > > E. If the list entry contains more than one of rfc822Name, > > > dNSName and iPAddress, and one or more of them match the > corresponding > > > fields in the matched certificate, then the username from the list > entry > > > is used.. > > > > > > [What happens if e.g. the dNSName matches but the rfc822Name does > not? > > > Needs clarifying IMO] > > > > > > F. If the commonName matches that in the matched certificate, > > > then the username from the list entry is used.. > > > > > > G. If none of the steps above yield an acceptable username, > then > > > additional list entries MUST be searched looking for a further > > > certificate match. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Ersue, Mehmet (NSN - DE/Munich)" > > > To: > > > Sent: Friday, January 30, 2015 2:17 PM > > > Subject: [Netconf] FW: WG Last Call for > draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > Dear NETCONF WG, > > > > > > > > we think the WGLC of the draft-ietf-netconf-rfc5539bis was > successful > > > > with useful comments and discussion. Based on the WGLC result > Juergen > > > > provided draft-ietf-netconf-rfc5539bis-08. > > > > > > > > See http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08 > > > > > > > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-08.txt > > > > > > > > Please look at v08 of the draft and let the co-chairs know by > February > > > 4, > > > > 2015 EOB PT, whether you have any objections to starting the > > > publications > > > > process and asking our AD Benoit Claise to do his review. > > > > > > > > Best Regards, > > > > Mehmet and Mahesh > > > > > > > > > > > > -----Original Message----- > > > > From: ext Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > > Sent: Tuesday, January 27, 2015 8:24 AM > > > > To: Ersue, Mehmet (NSN - DE/Munich) > > > > Cc: netconf@ietf.org > > > > Subject: Re: [Netconf] WG Last Call for > > > draft-ietf-netconf-rfc5539bis-07 > > > > > > > > On Mon, Jan 05, 2015 at 08:46:09PM +0000, Ersue, Mehmet (NSN - > > > DE/Munich) wrote: > > > > > Dear NETCONF Members, > > > > > > > > > > we hereby issue a WG Last Call for > draft-ietf-netconf-rfc5539bis-07. > > > > > > > > > > The document can be found at: > > > > > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > Please review and send your comments to the WG mailing list by > > > January 19, 2015 EOB PT. > > > > > > > > > > > > > Mehmet and Mahesh, > > > > > > > > I have posted draft-ietf-netconf-rfc5539bis-08 which I believe > > > > addresses the WG last call comments. Please check and if you > agree, > > > > please produce a document writeup and move the I-D over to the > IESG. > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > Germany > > > > Fax: +49 421 200 3103 > > > > > > > > _______________________________________________ > > > > 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 --YZ5djTAD1cGYuMQK Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-netconf-rfc5539bis-09-from-8.diff.html" Diff: draft-ietf-netconf-rfc5539bis-08.txt - draft-ietf-netconf-rfc5539bis-09.txt
 draft-ietf-netconf-rfc5539bis-08.txt   draft-ietf-netconf-rfc5539bis-09.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: July 31, 2015 J. Schoenwaelder Expires: August 16, 2015 J. Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
January 27, 2015 February 12, 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-08 draft-ietf-netconf-rfc5539bis-09
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 July 31, 2015. This Internet-Draft will expire on August 16, 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . 4
6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4 6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4
7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4 7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4
8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 8 Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 9
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 8 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9
B.1. draft-ietf-netconf-rfc5539bis-07 . . . . . . . . . . . . 8 B.1. draft-ietf-netconf-rfc5539bis-07 . . . . . . . . . . . . 9
B.2. draft-ietf-netconf-rfc5539bis-06 . . . . . . . . . . . . 9 B.2. draft-ietf-netconf-rfc5539bis-06 . . . . . . . . . . . . 9
B.3. draft-ietf-netconf-rfc5539bis-05 . . . . . . . . . . . . 9 B.3. draft-ietf-netconf-rfc5539bis-05 . . . . . . . . . . . . 10
B.4. draft-ietf-netconf-rfc5539bis-04 . . . . . . . . . . . . 9 B.4. draft-ietf-netconf-rfc5539bis-04 . . . . . . . . . . . . 10
B.5. draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . 9 B.5. draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . 10
B.6. draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . 9 B.6. draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . 10
B.7. draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . 10 B.7. draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 4, line 31 skipping to change at page 4, line 31
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
legitimate before the NETCONF session is started. legitimate before the NETCONF session is started.
The NETCONF protocol [RFC6241] requires that the transport protocol's The NETCONF protocol [RFC6241] requires that the transport protocol's
authentication process results in an authenticated NETCONF client authentication process results in an authenticated NETCONF client
identity whose permissions are known to the server. The identity whose permissions are known to the server. The
authenticated identity of a client is commonly referred to as the authenticated identity of a client is commonly referred to as the
NETCONF username. The following algorithm is used by the NETCONF NETCONF username. The following algorithm is used by the NETCONF
server to derive a NETCONF username from a certificate: server to derive a NETCONF username from a certificate. (Note that
the algorithm below is the same as the one described in the SNMP-TLS-
TM-MIB MIB module defined in [RFC6353] and in the ietf-x509-cert-to-
name YANG module defined in [RFC7407].)
o The server maintains an ordered list of mappings of certificates (a) The server maintains an ordered list of mappings of certificates
to NETCONF usernames. The username is derived by considering each to NETCONF usernames. Each list entry contains
list entry in order. The fingerprint member of a list entry
determines whether the list entry is a match:
1. If the list entry's fingerprint value matches that of the * a certificate fingerprint (used for matching the presented
presented certificate, then consider the list entry as a certificate),
successful match.
* a map type (indicates how the NETCONF username is derived
from the certificate), and
* optional auxiliary data (used to carry a NETCONF username if
the map type indicates the user name is explicitely
configured).
(b) The NETCONF username is derived by considering each list entry
in order. The fingerprint member of the current list entry
determines whether the current list entry is a match:
1. If the list entry's fingerprint value matches the
fingerprint of the presented certificate, then consider the
list entry as a successful match.
2. If the list entry's fingerprint value matches that of a 2. If the list entry's fingerprint value matches that of a
locally held copy of a trusted CA certificate, and that CA locally held copy of a trusted CA certificate, and that CA
certificate was part of the CA certificate chain to the certificate was part of the CA certificate chain to the
presented certificate, then consider the list entry as a presented certificate, then consider the list entry as a
successful match. successful match.
o Once a matching list entry has been found, the mapping type (c) Once a matching list entry has been found, the map type of the
property of the list entry is used to determine how the username current list entry is used to determine how the username
associated with the certificate should be determined. Possible associated with the certificate should be determined. Possible
mapping options are: mapping options are:
A. The username is explicitly configured. A. The username is taken from the auxiliary data of the current
list entry. This means the username is explicitely
configured (map type 'specified').
B. The subjectAltName's rfc822Name is mapped to a username. B. The subjectAltName's rfc822Name field is mapped to the
username (map type 'san-rfc822-name'). The local part of
the rfc822Name is used unaltered but the host-part of the
name must be converted to lowercase.
C. The subjectAltName's dNSName is mapped to a username. C. The subjectAltName's dNSName is mapped to the username (map
type 'san-dns-name'). The characters of the dNSName are
converted to lowercase.
D. The subjectAltName's iPAddress is mapped to a username. D. The subjectAltName's iPAddress is mapped to the username
(map type 'san-ip-address'). IPv4 addresses are converted
into decimal-dotted quad notation (e.g., '192.0.2.1'). IPv6
addresses are converted into a 32-character all lowercase
hexadecimal string without any colon separators.
E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress is E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress
mapped to a username. is mapped to the username (map type 'san-any'). The first
matching subjectAltName value found in the certificate of
the above types MUST be used when deriving the name.
F. The certificate's CommonName is mapped to a username. F. The certificate's CommonName is mapped to the username (map
type 'common-name'). The CommonName is converted to UTF-8
encoding. The usage of CommonNames is deprecated and users
are encouraged to use subjectAltName mapping methods
instead.
o If it is impossible to determine a username from the list entry's (d) If it is impossible to determine a username from the list
data combined with the data presented in the certificate, then entry's data combined with the data presented in the
additional list entries MUST be searched looking for another certificate, then additional list entries MUST be searched
potential match. Similarily, if the username does not comply to looking for another potential match. Similarily, if the
the NETCONF requirements on usernames [RFC6241] (i.e., the username does not comply to the NETCONF requirements on
username is not representable in XML), then additional list usernames [RFC6241] (i.e., the username is not representable in
entries MUST be searched looking for another potential match. If XML), then additional list entries MUST be searched looking for
there are no further list entries, the TLS session MUST be another potential match. If there are no further list entries,
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.
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
skipping to change at page 8, line 20 skipping to change at page 9, line 5
12.2. Informative References 12.2. Informative References
[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
Model for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 6353, July 2011.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, December 2014.
Appendix A. Changes from RFC 5539 Appendix A. Changes from RFC 5539
This section summarizes major changes between this document and RFC This section summarizes major changes between this document and RFC
5539. 5539.
o Documented that NETCONF over TLS uses the new message framing if o Documented that NETCONF over TLS uses the new message framing if
both peers support the :base:1.1 capability. both peers support the :base:1.1 capability.
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
 End of changes. 20 change blocks. 
43 lines changed or deleted 82 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/
--YZ5djTAD1cGYuMQK-- From nobody Thu Feb 12 04:08:59 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A371A1AEB for ; Thu, 12 Feb 2015 04:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 ItYQCqtrXhSX for ; Thu, 12 Feb 2015 04:08:50 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E9C1A1AA3 for ; Thu, 12 Feb 2015 04:08:49 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.81.19; Thu, 12 Feb 2015 12:08:33 +0000 Message-ID: <004601d046bc$62d0ee40$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <019601d0406b$16414900$4001a8c0@gateway.2wire.net> <20150209170119.GB21527@elstar.local> <01b101d045f4$b19c6d60$4001a8c0@gateway.2wire.net> <20150212074240.GC9173@elstar.local> Date: Thu, 12 Feb 2015 11:59:21 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: AMSPR02CA0044.eurprd02.prod.outlook.com (10.242.225.172) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: jacobs-university.de; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 0485417665 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(377454003)(44716002)(62236002)(50986999)(50466002)(23756003)(47776003)(50226001)(76176999)(46102003)(15975445007)(44736004)(1720100001)(33646002)(77096005)(230783001)(116806002)(92566002)(93886004)(66066001)(62966003)(77156002)(122386002)(19580395003)(19580405001)(40100003)(110136001)(87976001)(86362001)(42186005)(81686999)(81816999)(14496001)(61296003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2015 12:08:33.6042 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 12:08:57 -0000 Juergen Yes, I now appreciate the depths of my original misunderstanding! Looks good. (As you may have guessed, I consciously did not look at anything that was not a Normative Reference so as not to know more that a reader might be expected to know). Perhaps /explicitely/explicitly/ Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Cc: "Ersue, Mehmet (NSN - DE/Munich)" ; Sent: Thursday, February 12, 2015 7:42 AM Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 > Hi, > > here is another attempt, incorporating more text from the RFCs that > originally defined this algorithm. > > /js > > On Wed, Feb 11, 2015 at 12:15:37PM +0000, t. petch wrote: > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > To: "t. petch" > > Sent: Monday, February 09, 2015 5:01 PM > > > > > Hi, > > > > > > apparently the text is not clear enough since your interpretation > > > seems to be somewhat incorrect. Does the attached rfcdiff resolve the > > > issue? > > > > Yes, my interpretation was incorrect and this is clearer but I am still > > left uncertain over steps A to F when they say e.g. > > > > D. The subjectAltName's iPAddress is mapped to the username > > (map type 'san-ip-address'). > > > > How is it mapped? I assume that an iPAddress cannot be a username per > > se(!) so I imagine that there needs to be a data structure with a list > > of iPAddress and corresponding username. Since -08 only mentioned the > > one data structure, I rolled everything into that data structure. Your > > rewording leads me to create a second data structure mapping the various > > fields from the certificate to a username. If so, I think that this is > > worth a mention under a). > > > > A minor comment; I would prefer a consistent identifier for 'map type', > > such as 'map type' - currently, you have 'mapping type', 'mapping type > > property' and 'map type', > > > > Tom Petch > > > > > > > > /js > > > > > > On Wed, Feb 04, 2015 at 11:09:38AM +0000, t. petch wrote: > > > > I think that with the removal of the reference to server model, then > > the > > > > steps in section 7 become hard to follow, almost incomprehensible - > > they > > > > presume an information model which is not specified. I think that > > > > Martin's comments revolved around this issue and that it is > > > > insufficiently resolved. So I would rewrite section 7, not changing > > the > > > > meaning one iota (well, if I have, then I think the section must be > > > > incomprehensible:-) > > > > > > > > OLD > > > > o The server maintains an ordered list of mappings of certificates > > > > to NETCONF usernames. The username is derived by considering > > each > > > > list entry in order. The fingerprint member of a list entry > > > > determines whether the list entry is a match: > > > > > > > > 1. If the list entry's fingerprint value matches that of the > > > > presented certificate, then consider the list entry as a > > > > successful match. > > > > > > > > 2. If the list entry's fingerprint value matches that of a > > > > locally held copy of a trusted CA certificate, and that CA > > > > certificate was part of the CA certificate chain to the > > > > presented certificate, then consider the list entry as a > > > > successful match. > > > > > > > > o Once a matching list entry has been found, the mapping type > > > > property of the list entry is used to determine how the > > username > > > > associated with the certificate should be determined. > > Possible > > > > mapping options are: > > > > > > > > A. The username is explicitly configured. > > > > > > > > B. The subjectAltName's rfc822Name is mapped to a username. > > > > > > > > C. The subjectAltName's dNSName is mapped to a username. > > > > > > > > D. The subjectAltName's iPAddress is mapped to a username. > > > > > > > > E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress > > is > > > > mapped to a username. > > > > > > > > F. The certificate's CommonName is mapped to a username. > > > > > > > > o If it is impossible to determine a username from the list > > entry's > > > > data combined with the data presented in the certificate, then > > > > additional list entries MUST be searched looking for another > > > > potential match. Similarily, if the username does not comply > > to > > > > the NETCONF requirements on usernames [RFC6241] (i.e., the > > > > username is not representable in XML), then additional list > > > > entries MUST be searched looking for another potential match. > > If > > > > there are no further list entries, the TLS session MUST be > > > > terminated. > > > > > > > > NEW > > > > > > > > o The server maintains an ordered list, with each entry containing > > a > > > > certificate fingerprint, a NETCONF username and, optionally, one or > > more > > > > fields that may appear in the certificate, namely the rfc822Name, > > > > dNSName or iPAddress as they appear in the subjectAltName field, or > > the > > > > commonName [X520CommonName?] . > > > > > > > > The username is derived by considering each list entry in order. > > If > > > > the list entry matches the presented certificate, then further > > checks > > > > are carried out based on the list entry. If these result in an > > > > acceptable username, then the search terminates. If the username is > > not > > > > acceptable, then the search continues with the next list entry. If > > > > there are no further list entries, the TLS session MUST be > > terminated. > > > > > > > > The test for a matching certificate is as follows. > > > > > > > > 1. If the fingerprint value of the list entry matches the > > > > fingerprint of the > > > > presented certificate, then consider the list entry as a > > > > successful match. > > > > > > > > 2. If the fingerprint value of the list entry matches that of > > a > > > > locally held copy of a trusted CA certificate, and that CA > > > > certificate was part of the CA certificate chain to the > > > > presented certificate, then consider the list entry as a > > > > successful match. > > > > > > > > Once a matching list entry has been found, the list entry is > > considered > > > > further. If the username does not comply to the NETCONF > > requirements on > > > > usernames [RFC6241] (i.e., the username is not representable in > > XML), > > > > then the username is not acceptable and list entries MUST be > > searched > > > > looking for another certificate match. > > > > > > > > A. If the list entry contains just a compliant username, then > > > > that username is used. > > > > > > > > B. If the list entry contains just an rfc822Name which > > matches > > > > that in the matched certificate, then the username from the list > > entry > > > > is used.. > > > > > > > > C. If the list entry contains just a dNSName which matches > > that > > > > in the matched certificate, then the username from the list entry is > > > > used.. > > > > > > > > D. If the list entry contains just an iPAddress which matches > > > > that in the matched certificate, then the username from the list > > entry > > > > is used.. > > > > . > > > > E. If the list entry contains more than one of rfc822Name, > > > > dNSName and iPAddress, and one or more of them match the > > corresponding > > > > fields in the matched certificate, then the username from the list > > entry > > > > is used.. > > > > > > > > [What happens if e.g. the dNSName matches but the rfc822Name does > > not? > > > > Needs clarifying IMO] > > > > > > > > F. If the commonName matches that in the matched certificate, > > > > then the username from the list entry is used.. > > > > > > > > G. If none of the steps above yield an acceptable username, > > then > > > > additional list entries MUST be searched looking for a further > > > > certificate match. > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "Ersue, Mehmet (NSN - DE/Munich)" > > > > To: > > > > Sent: Friday, January 30, 2015 2:17 PM > > > > Subject: [Netconf] FW: WG Last Call for > > draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > > > > Dear NETCONF WG, > > > > > > > > > > we think the WGLC of the draft-ietf-netconf-rfc5539bis was > > successful > > > > > with useful comments and discussion. Based on the WGLC result > > Juergen > > > > > provided draft-ietf-netconf-rfc5539bis-08. > > > > > > > > > > See http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08 > > > > > > > > > > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-08.txt > > > > > > > > > > Please look at v08 of the draft and let the co-chairs know by > > February > > > > 4, > > > > > 2015 EOB PT, whether you have any objections to starting the > > > > publications > > > > > process and asking our AD Benoit Claise to do his review. > > > > > > > > > > Best Regards, > > > > > Mehmet and Mahesh > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ext Juergen Schoenwaelder > > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > > > Sent: Tuesday, January 27, 2015 8:24 AM > > > > > To: Ersue, Mehmet (NSN - DE/Munich) > > > > > Cc: netconf@ietf.org > > > > > Subject: Re: [Netconf] WG Last Call for > > > > draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > On Mon, Jan 05, 2015 at 08:46:09PM +0000, Ersue, Mehmet (NSN - > > > > DE/Munich) wrote: > > > > > > Dear NETCONF Members, > > > > > > > > > > > > we hereby issue a WG Last Call for > > draft-ietf-netconf-rfc5539bis-07. > > > > > > > > > > > > The document can be found at: > > > > > > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > > > Please review and send your comments to the WG mailing list by > > > > January 19, 2015 EOB PT. > > > > > > > > > > > > > > > > Mehmet and Mahesh, > > > > > > > > > > I have posted draft-ietf-netconf-rfc5539bis-08 which I believe > > > > > addresses the WG last call comments. Please check and if you > > agree, > > > > > please produce a document writeup and move the I-D over to the > > IESG. > > > > > > > > > > /js > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > > Germany > > > > > Fax: +49 421 200 3103 > > > > > > > > > > _______________________________________________ > > > > > 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 Feb 12 04:23:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A967C1A1BA7 for ; Thu, 12 Feb 2015 04:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wISE42SZ5fi5 for ; Thu, 12 Feb 2015 04:23:43 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35631A1B9C for ; Thu, 12 Feb 2015 04:23:42 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8A23B1861; Thu, 12 Feb 2015 13:23:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nNYtO_GgGEBq; Thu, 12 Feb 2015 13:23:19 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 12 Feb 2015 13:23:39 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 664D320037; Thu, 12 Feb 2015 13:23:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id F7wlMStl-p_y; Thu, 12 Feb 2015 13:23:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F65820036; Thu, 12 Feb 2015 13:23:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A730A3205A74; Thu, 12 Feb 2015 13:23:34 +0100 (CET) Date: Thu, 12 Feb 2015 13:23:34 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20150212122334.GC6640@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "t. petch" , netconf@ietf.org References: <019601d0406b$16414900$4001a8c0@gateway.2wire.net> <20150209170119.GB21527@elstar.local> <01b101d045f4$b19c6d60$4001a8c0@gateway.2wire.net> <20150212074240.GC9173@elstar.local> <004601d046bc$62d0ee40$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004601d046bc$62d0ee40$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 12:23:48 -0000 Mehmet, shall I post -09 and what is the next step then? /js On Thu, Feb 12, 2015 at 11:59:21AM +0000, t. petch wrote: > Juergen > > Yes, I now appreciate the depths of my original misunderstanding! > Looks good. > > (As you may have guessed, I consciously did not look at anything that > was not a Normative Reference so as not to know more that a reader might > be expected to know). > > Perhaps > /explicitely/explicitly/ > > Tom Petch > > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "t. petch" > Cc: "Ersue, Mehmet (NSN - DE/Munich)" ; > > Sent: Thursday, February 12, 2015 7:42 AM > Subject: Re: [Netconf] FW: WG Last Call for > draft-ietf-netconf-rfc5539bis-07 > > > > Hi, > > > > here is another attempt, incorporating more text from the RFCs that > > originally defined this algorithm. > > > > /js > > > > On Wed, Feb 11, 2015 at 12:15:37PM +0000, t. petch wrote: > > > ----- Original Message ----- > > > From: "Juergen Schoenwaelder" > > > To: "t. petch" > > > Sent: Monday, February 09, 2015 5:01 PM > > > > > > > Hi, > > > > > > > > apparently the text is not clear enough since your interpretation > > > > seems to be somewhat incorrect. Does the attached rfcdiff resolve > the > > > > issue? > > > > > > Yes, my interpretation was incorrect and this is clearer but I am > still > > > left uncertain over steps A to F when they say e.g. > > > > > > D. The subjectAltName's iPAddress is mapped to the username > > > (map type 'san-ip-address'). > > > > > > How is it mapped? I assume that an iPAddress cannot be a username > per > > > se(!) so I imagine that there needs to be a data structure with a > list > > > of iPAddress and corresponding username. Since -08 only mentioned > the > > > one data structure, I rolled everything into that data structure. > Your > > > rewording leads me to create a second data structure mapping the > various > > > fields from the certificate to a username. If so, I think that this > is > > > worth a mention under a). > > > > > > A minor comment; I would prefer a consistent identifier for 'map > type', > > > such as 'map type' - currently, you have 'mapping type', 'mapping > type > > > property' and 'map type', > > > > > > Tom Petch > > > > > > > > > > > /js > > > > > > > > On Wed, Feb 04, 2015 at 11:09:38AM +0000, t. petch wrote: > > > > > I think that with the removal of the reference to server model, > then > > > the > > > > > steps in section 7 become hard to follow, almost > incomprehensible - > > > they > > > > > presume an information model which is not specified. I think > that > > > > > Martin's comments revolved around this issue and that it is > > > > > insufficiently resolved. So I would rewrite section 7, not > changing > > > the > > > > > meaning one iota (well, if I have, then I think the section must > be > > > > > incomprehensible:-) > > > > > > > > > > OLD > > > > > o The server maintains an ordered list of mappings of > certificates > > > > > to NETCONF usernames. The username is derived by > considering > > > each > > > > > list entry in order. The fingerprint member of a list > entry > > > > > determines whether the list entry is a match: > > > > > > > > > > 1. If the list entry's fingerprint value matches that of > the > > > > > presented certificate, then consider the list entry as > a > > > > > successful match. > > > > > > > > > > 2. If the list entry's fingerprint value matches that of > a > > > > > locally held copy of a trusted CA certificate, and > that CA > > > > > certificate was part of the CA certificate chain to > the > > > > > presented certificate, then consider the list entry as > a > > > > > successful match. > > > > > > > > > > o Once a matching list entry has been found, the mapping > type > > > > > property of the list entry is used to determine how the > > > username > > > > > associated with the certificate should be determined. > > > Possible > > > > > mapping options are: > > > > > > > > > > A. The username is explicitly configured. > > > > > > > > > > B. The subjectAltName's rfc822Name is mapped to a > username. > > > > > > > > > > C. The subjectAltName's dNSName is mapped to a username. > > > > > > > > > > D. The subjectAltName's iPAddress is mapped to a > username. > > > > > > > > > > E. Any of the subjectAltName's rfc822Name, dNSName, > iPAddress > > > is > > > > > mapped to a username. > > > > > > > > > > F. The certificate's CommonName is mapped to a username. > > > > > > > > > > o If it is impossible to determine a username from the list > > > entry's > > > > > data combined with the data presented in the certificate, > then > > > > > additional list entries MUST be searched looking for > another > > > > > potential match. Similarily, if the username does not > comply > > > to > > > > > the NETCONF requirements on usernames [RFC6241] (i.e., the > > > > > username is not representable in XML), then additional > list > > > > > entries MUST be searched looking for another potential > match. > > > If > > > > > there are no further list entries, the TLS session MUST be > > > > > terminated. > > > > > > > > > > NEW > > > > > > > > > > o The server maintains an ordered list, with each entry > containing > > > a > > > > > certificate fingerprint, a NETCONF username and, optionally, one > or > > > more > > > > > fields that may appear in the certificate, namely the > rfc822Name, > > > > > dNSName or iPAddress as they appear in the subjectAltName field, > or > > > the > > > > > commonName [X520CommonName?] . > > > > > > > > > > The username is derived by considering each list entry in > order. > > > If > > > > > the list entry matches the presented certificate, then further > > > checks > > > > > are carried out based on the list entry. If these result in an > > > > > acceptable username, then the search terminates. If the > username is > > > not > > > > > acceptable, then the search continues with the next list entry. > If > > > > > there are no further list entries, the TLS session MUST be > > > terminated. > > > > > > > > > > The test for a matching certificate is as follows. > > > > > > > > > > 1. If the fingerprint value of the list entry matches the > > > > > fingerprint of the > > > > > presented certificate, then consider the list entry as > a > > > > > successful match. > > > > > > > > > > 2. If the fingerprint value of the list entry matches > that of > > > a > > > > > locally held copy of a trusted CA certificate, and > that CA > > > > > certificate was part of the CA certificate chain to > the > > > > > presented certificate, then consider the list entry as > a > > > > > successful match. > > > > > > > > > > Once a matching list entry has been found, the list entry is > > > considered > > > > > further. If the username does not comply to the NETCONF > > > requirements on > > > > > usernames [RFC6241] (i.e., the username is not representable in > > > XML), > > > > > then the username is not acceptable and list entries MUST be > > > searched > > > > > looking for another certificate match. > > > > > > > > > > A. If the list entry contains just a compliant username, > then > > > > > that username is used. > > > > > > > > > > B. If the list entry contains just an rfc822Name which > > > matches > > > > > that in the matched certificate, then the username from the list > > > entry > > > > > is used.. > > > > > > > > > > C. If the list entry contains just a dNSName which > matches > > > that > > > > > in the matched certificate, then the username from the list > entry is > > > > > used.. > > > > > > > > > > D. If the list entry contains just an iPAddress which > matches > > > > > that in the matched certificate, then the username from the list > > > entry > > > > > is used.. > > > > > . > > > > > E. If the list entry contains more than one of > rfc822Name, > > > > > dNSName and iPAddress, and one or more of them match the > > > corresponding > > > > > fields in the matched certificate, then the username from the > list > > > entry > > > > > is used.. > > > > > > > > > > [What happens if e.g. the dNSName matches but the rfc822Name > does > > > not? > > > > > Needs clarifying IMO] > > > > > > > > > > F. If the commonName matches that in the matched > certificate, > > > > > then the username from the list entry is used.. > > > > > > > > > > G. If none of the steps above yield an acceptable > username, > > > then > > > > > additional list entries MUST be searched looking for a further > > > > > certificate match. > > > > > > > > > > Tom Petch > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ersue, Mehmet (NSN - DE/Munich)" > > > > > To: > > > > > Sent: Friday, January 30, 2015 2:17 PM > > > > > Subject: [Netconf] FW: WG Last Call for > > > draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > > > > > > > Dear NETCONF WG, > > > > > > > > > > > > we think the WGLC of the draft-ietf-netconf-rfc5539bis was > > > successful > > > > > > with useful comments and discussion. Based on the WGLC result > > > Juergen > > > > > > provided draft-ietf-netconf-rfc5539bis-08. > > > > > > > > > > > > See > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08 > > > > > > > > > > > > > > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-08.txt > > > > > > > > > > > > Please look at v08 of the draft and let the co-chairs know by > > > February > > > > > 4, > > > > > > 2015 EOB PT, whether you have any objections to starting the > > > > > publications > > > > > > process and asking our AD Benoit Claise to do his review. > > > > > > > > > > > > Best Regards, > > > > > > Mehmet and Mahesh > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Juergen Schoenwaelder > > > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > > > > Sent: Tuesday, January 27, 2015 8:24 AM > > > > > > To: Ersue, Mehmet (NSN - DE/Munich) > > > > > > Cc: netconf@ietf.org > > > > > > Subject: Re: [Netconf] WG Last Call for > > > > > draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > > > On Mon, Jan 05, 2015 at 08:46:09PM +0000, Ersue, Mehmet (NSN - > > > > > DE/Munich) wrote: > > > > > > > Dear NETCONF Members, > > > > > > > > > > > > > > we hereby issue a WG Last Call for > > > draft-ietf-netconf-rfc5539bis-07. > > > > > > > > > > > > > > The document can be found at: > > > > > > > > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > > > > > Please review and send your comments to the WG mailing list > by > > > > > January 19, 2015 EOB PT. > > > > > > > > > > > > > > > > > > > Mehmet and Mahesh, > > > > > > > > > > > > I have posted draft-ietf-netconf-rfc5539bis-08 which I believe > > > > > > addresses the WG last call comments. Please check and if you > > > agree, > > > > > > please produce a document writeup and move the I-D over to the > > > IESG. > > > > > > > > > > > > /js > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > > > Germany > > > > > > Fax: +49 421 200 3103 > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 12 07:31: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 09F781A8AC1 for ; Thu, 12 Feb 2015 07:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlVa5y-gdxgR for ; Thu, 12 Feb 2015 07:30:58 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D35B1A9133 for ; Thu, 12 Feb 2015 07:30:43 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t1CFUcHd009209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Feb 2015 15:30:38 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 t1CFUb0A003846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 16:30:37 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 12 Feb 2015 16:30:36 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 16:30:37 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Juergen Schoenwaelder Thread-Topic: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 Thread-Index: AQHQRtjZWx1Sj/LUf0iDyWV3HrHqrQ== Date: Thu, 12 Feb 2015 15:30:36 +0000 Message-ID: References: <019601d0406b$16414900$4001a8c0@gateway.2wire.net> <20150209170119.GB21527@elstar.local> <01b101d045f4$b19c6d60$4001a8c0@gateway.2wire.net> <20150212074240.GC9173@elstar.local> <004601d046bc$62d0ee40$4001a8c0@gateway.2wire.net> <20150212122334.GC6640@elstar.local> In-Reply-To: <20150212122334.GC6640@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 13664 X-purgate-ID: 151667::1423755038-000067C4-894919AE/0/0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 15:31:05 -0000 Hi Juergen, please do upload -09 after this final agreement. We need to give the WG at least 3-4 days to comment on -09 before=20 asking our AD for review and starting the IESG process. Cheers,=20 Mehmet=20 -----Original Message----- From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Thursday, February 12, 2015 1:24 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: t. petch; netconf@ietf.org Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-0= 7 Mehmet, shall I post -09 and what is the next step then? /js On Thu, Feb 12, 2015 at 11:59:21AM +0000, t. petch wrote: > Juergen >=20 > Yes, I now appreciate the depths of my original misunderstanding! > Looks good. >=20 > (As you may have guessed, I consciously did not look at anything that > was not a Normative Reference so as not to know more that a reader might > be expected to know). >=20 > Perhaps > /explicitely/explicitly/ >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "t. petch" > Cc: "Ersue, Mehmet (NSN - DE/Munich)" ; > > Sent: Thursday, February 12, 2015 7:42 AM > Subject: Re: [Netconf] FW: WG Last Call for > draft-ietf-netconf-rfc5539bis-07 >=20 >=20 > > Hi, > > > > here is another attempt, incorporating more text from the RFCs that > > originally defined this algorithm. > > > > /js > > > > On Wed, Feb 11, 2015 at 12:15:37PM +0000, t. petch wrote: > > > ----- Original Message ----- > > > From: "Juergen Schoenwaelder" > > > To: "t. petch" > > > Sent: Monday, February 09, 2015 5:01 PM > > > > > > > Hi, > > > > > > > > apparently the text is not clear enough since your interpretation > > > > seems to be somewhat incorrect. Does the attached rfcdiff resolve > the > > > > issue? > > > > > > Yes, my interpretation was incorrect and this is clearer but I am > still > > > left uncertain over steps A to F when they say e.g. > > > > > > D. The subjectAltName's iPAddress is mapped to the username > > > (map type 'san-ip-address'). > > > > > > How is it mapped? I assume that an iPAddress cannot be a username > per > > > se(!) so I imagine that there needs to be a data structure with a > list > > > of iPAddress and corresponding username. Since -08 only mentioned > the > > > one data structure, I rolled everything into that data structure. > Your > > > rewording leads me to create a second data structure mapping the > various > > > fields from the certificate to a username. If so, I think that this > is > > > worth a mention under a). > > > > > > A minor comment; I would prefer a consistent identifier for 'map > type', > > > such as 'map type' - currently, you have 'mapping type', 'mapping > type > > > property' and 'map type', > > > > > > Tom Petch > > > > > > > > > > > /js > > > > > > > > On Wed, Feb 04, 2015 at 11:09:38AM +0000, t. petch wrote: > > > > > I think that with the removal of the reference to server model, > then > > > the > > > > > steps in section 7 become hard to follow, almost > incomprehensible - > > > they > > > > > presume an information model which is not specified. I think > that > > > > > Martin's comments revolved around this issue and that it is > > > > > insufficiently resolved. So I would rewrite section 7, not > changing > > > the > > > > > meaning one iota (well, if I have, then I think the section must > be > > > > > incomprehensible:-) > > > > > > > > > > OLD > > > > > o The server maintains an ordered list of mappings of > certificates > > > > > to NETCONF usernames. The username is derived by > considering > > > each > > > > > list entry in order. The fingerprint member of a list > entry > > > > > determines whether the list entry is a match: > > > > > > > > > > 1. If the list entry's fingerprint value matches that of > the > > > > > presented certificate, then consider the list entry as > a > > > > > successful match. > > > > > > > > > > 2. If the list entry's fingerprint value matches that of > a > > > > > locally held copy of a trusted CA certificate, and > that CA > > > > > certificate was part of the CA certificate chain to > the > > > > > presented certificate, then consider the list entry as > a > > > > > successful match. > > > > > > > > > > o Once a matching list entry has been found, the mapping > type > > > > > property of the list entry is used to determine how the > > > username > > > > > associated with the certificate should be determined. > > > Possible > > > > > mapping options are: > > > > > > > > > > A. The username is explicitly configured. > > > > > > > > > > B. The subjectAltName's rfc822Name is mapped to a > username. > > > > > > > > > > C. The subjectAltName's dNSName is mapped to a username. > > > > > > > > > > D. The subjectAltName's iPAddress is mapped to a > username. > > > > > > > > > > E. Any of the subjectAltName's rfc822Name, dNSName, > iPAddress > > > is > > > > > mapped to a username. > > > > > > > > > > F. The certificate's CommonName is mapped to a username. > > > > > > > > > > o If it is impossible to determine a username from the list > > > entry's > > > > > data combined with the data presented in the certificate, > then > > > > > additional list entries MUST be searched looking for > another > > > > > potential match. Similarily, if the username does not > comply > > > to > > > > > the NETCONF requirements on usernames [RFC6241] (i.e., the > > > > > username is not representable in XML), then additional > list > > > > > entries MUST be searched looking for another potential > match. > > > If > > > > > there are no further list entries, the TLS session MUST be > > > > > terminated. > > > > > > > > > > NEW > > > > > > > > > > o The server maintains an ordered list, with each entry > containing > > > a > > > > > certificate fingerprint, a NETCONF username and, optionally, one > or > > > more > > > > > fields that may appear in the certificate, namely the > rfc822Name, > > > > > dNSName or iPAddress as they appear in the subjectAltName field, > or > > > the > > > > > commonName [X520CommonName?] . > > > > > > > > > > The username is derived by considering each list entry in > order. > > > If > > > > > the list entry matches the presented certificate, then further > > > checks > > > > > are carried out based on the list entry. If these result in an > > > > > acceptable username, then the search terminates. If the > username is > > > not > > > > > acceptable, then the search continues with the next list entry. > If > > > > > there are no further list entries, the TLS session MUST be > > > terminated. > > > > > > > > > > The test for a matching certificate is as follows. > > > > > > > > > > 1. If the fingerprint value of the list entry matches the > > > > > fingerprint of the > > > > > presented certificate, then consider the list entry as > a > > > > > successful match. > > > > > > > > > > 2. If the fingerprint value of the list entry matches > that of > > > a > > > > > locally held copy of a trusted CA certificate, and > that CA > > > > > certificate was part of the CA certificate chain to > the > > > > > presented certificate, then consider the list entry as > a > > > > > successful match. > > > > > > > > > > Once a matching list entry has been found, the list entry is > > > considered > > > > > further. If the username does not comply to the NETCONF > > > requirements on > > > > > usernames [RFC6241] (i.e., the username is not representable in > > > XML), > > > > > then the username is not acceptable and list entries MUST be > > > searched > > > > > looking for another certificate match. > > > > > > > > > > A. If the list entry contains just a compliant username, > then > > > > > that username is used. > > > > > > > > > > B. If the list entry contains just an rfc822Name which > > > matches > > > > > that in the matched certificate, then the username from the list > > > entry > > > > > is used.. > > > > > > > > > > C. If the list entry contains just a dNSName which > matches > > > that > > > > > in the matched certificate, then the username from the list > entry is > > > > > used.. > > > > > > > > > > D. If the list entry contains just an iPAddress which > matches > > > > > that in the matched certificate, then the username from the list > > > entry > > > > > is used.. > > > > > . > > > > > E. If the list entry contains more than one of > rfc822Name, > > > > > dNSName and iPAddress, and one or more of them match the > > > corresponding > > > > > fields in the matched certificate, then the username from the > list > > > entry > > > > > is used.. > > > > > > > > > > [What happens if e.g. the dNSName matches but the rfc822Name > does > > > not? > > > > > Needs clarifying IMO] > > > > > > > > > > F. If the commonName matches that in the matched > certificate, > > > > > then the username from the list entry is used.. > > > > > > > > > > G. If none of the steps above yield an acceptable > username, > > > then > > > > > additional list entries MUST be searched looking for a further > > > > > certificate match. > > > > > > > > > > Tom Petch > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ersue, Mehmet (NSN - DE/Munich)" > > > > > To: > > > > > Sent: Friday, January 30, 2015 2:17 PM > > > > > Subject: [Netconf] FW: WG Last Call for > > > draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > > > > > > > Dear NETCONF WG, > > > > > > > > > > > > we think the WGLC of the draft-ietf-netconf-rfc5539bis was > > > successful > > > > > > with useful comments and discussion. Based on the WGLC result > > > Juergen > > > > > > provided draft-ietf-netconf-rfc5539bis-08. > > > > > > > > > > > > See > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08 > > > > > > > > > > > > > > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-08.txt > > > > > > > > > > > > Please look at v08 of the draft and let the co-chairs know by > > > February > > > > > 4, > > > > > > 2015 EOB PT, whether you have any objections to starting the > > > > > publications > > > > > > process and asking our AD Benoit Claise to do his review. > > > > > > > > > > > > Best Regards, > > > > > > Mehmet and Mahesh > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Juergen Schoenwaelder > > > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > > > > Sent: Tuesday, January 27, 2015 8:24 AM > > > > > > To: Ersue, Mehmet (NSN - DE/Munich) > > > > > > Cc: netconf@ietf.org > > > > > > Subject: Re: [Netconf] WG Last Call for > > > > > draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > > > On Mon, Jan 05, 2015 at 08:46:09PM +0000, Ersue, Mehmet (NSN - > > > > > DE/Munich) wrote: > > > > > > > Dear NETCONF Members, > > > > > > > > > > > > > > we hereby issue a WG Last Call for > > > draft-ietf-netconf-rfc5539bis-07. > > > > > > > > > > > > > > The document can be found at: > > > > > > > > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 > > > > > > > > > > > > > > Please review and send your comments to the WG mailing list > by > > > > > January 19, 2015 EOB PT. > > > > > > > > > > > > > > > > > > > Mehmet and Mahesh, > > > > > > > > > > > > I have posted draft-ietf-netconf-rfc5539bis-08 which I believe > > > > > > addresses the WG last call comments. Please check and if you > > > agree, > > > > > > please produce a document writeup and move the I-D over to the > > > IESG. > > > > > > > > > > > > /js > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > > > Germany > > > > > > Fax: +49 421 200 3103 > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > >=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 Thu Feb 12 07:56: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 965491A0011; Thu, 12 Feb 2015 07:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fXU85qOZtyx; Thu, 12 Feb 2015 07:55:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10ECB1A0006; Thu, 12 Feb 2015 07:55:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212155558.24348.56905.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 07:55:58 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-09.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: Thu, 12 Feb 2015 15:55:59 -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-09.txt Pages : 12 Date : 2015-02-12 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-09 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 Thu Feb 12 08: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 EC06E1A0037 for ; Thu, 12 Feb 2015 08:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHCxqZavjjMI for ; Thu, 12 Feb 2015 08:00:18 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28381A0046 for ; Thu, 12 Feb 2015 08:00:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7C1EB131C; Thu, 12 Feb 2015 17:00:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yq8fXgMxdmXl; Thu, 12 Feb 2015 16:59:43 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 12 Feb 2015 17:00:04 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD44D20039; Thu, 12 Feb 2015 17:00:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XRietN31D3-0; Thu, 12 Feb 2015 17:00:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8926020036; Thu, 12 Feb 2015 17:00:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 581C93207F9E; Thu, 12 Feb 2015 17:00:02 +0100 (CET) Date: Thu, 12 Feb 2015 17:00:02 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20150212160002.GB12402@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: <019601d0406b$16414900$4001a8c0@gateway.2wire.net> <20150209170119.GB21527@elstar.local> <01b101d045f4$b19c6d60$4001a8c0@gateway.2wire.net> <20150212074240.GC9173@elstar.local> <004601d046bc$62d0ee40$4001a8c0@gateway.2wire.net> <20150212122334.GC6640@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 16:00:22 -0000 On Thu, Feb 12, 2015 at 03:30:36PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Juergen, > > please do upload -09 after this final agreement. done > We need to give the WG at least 3-4 days to comment on -09 before > asking our AD for review and starting the IESG process. ack /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 12 08:07:20 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0A1A0010 for ; Thu, 12 Feb 2015 08:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaP-834cI3rn for ; Thu, 12 Feb 2015 08:07:15 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA6E1A0011 for ; Thu, 12 Feb 2015 08:07:14 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t1CG7CNl010445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Feb 2015 16:07:13 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t1CG7CS0003896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 17:07:12 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 17:07:11 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 Thread-Index: AQHQRtjZWx1Sj/LUf0iDyWV3HrHqrZztG3UAgAAR3VA= Date: Thu, 12 Feb 2015 16:07:11 +0000 Message-ID: References: <019601d0406b$16414900$4001a8c0@gateway.2wire.net> <20150209170119.GB21527@elstar.local> <01b101d045f4$b19c6d60$4001a8c0@gateway.2wire.net> <20150212074240.GC9173@elstar.local> <004601d046bc$62d0ee40$4001a8c0@gateway.2wire.net> <20150212122334.GC6640@elstar.local> <20150212160002.GB12402@elstar.local> In-Reply-To: <20150212160002.GB12402@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1227 X-purgate-ID: 151667::1423757233-00007286-4463C97C/0/0 Archived-At: Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 16:07:18 -0000 All, after solving the last remaining issue please look at -09 and comment withi= n 4 business days before we go to AD review and initiate the publication pr= ocess. The deadline for comments is February 18, 5pm CET. https://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-09 https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-09.txt= =20 Regards,=20 Mehmet=20 -----Original Message----- From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Thursday, February 12, 2015 5:00 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: netconf@ietf.org Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-0= 7 On Thu, Feb 12, 2015 at 03:30:36PM +0000, Ersue, Mehmet (NSN - DE/Munich) w= rote: > Hi Juergen, >=20 > please do upload -09 after this final agreement. done =20 > We need to give the WG at least 3-4 days to comment on -09 before=20 > asking our AD for review and starting the IESG process. ack /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 12 08:34: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 576421A00A2 for ; Thu, 12 Feb 2015 08:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Prxxp6YJjLCj for ; Thu, 12 Feb 2015 08:33:58 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578431A006F for ; Thu, 12 Feb 2015 08:33:58 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id bs8so5692932wib.0 for ; Thu, 12 Feb 2015 08:33:57 -0800 (PST) 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 :cc:content-type; bh=YCMjPI7ikGOONdRPFJqqfQ3YrOoxmEaJol16SQSr1hk=; b=xd9ymxn3Jytcjsx3ObfM8aU5peWZzSEvpZGx6zOLJTtRoN3t/L4ZrLJcHeEzbAFGDm L7GAQL2+52xFbVP5v0WI2igORVyufcXatD/HzVtdI8HYmHhOMlmzyuJMsdaJhqIwaTF6 cLguu9SOBQ4/jGc/rnI+WfNVj0UZBjdSP+ZGvdX7aQWfGhil01+86mv99mu5i8NQBBkJ 0d4HNcrPHZSYynrafoxwNnZ37jMOoeRwn04vdY42kPDgy7ErhekIyLiKoQOYutjqKCBn Vaw8pQ7pykl4ndEjcWwHvwHzoHntT8dgeVOeYZZli+t2DGKjGxjK7klkDBw+RxuEtY0h 5biA== MIME-Version: 1.0 X-Received: by 10.194.205.228 with SMTP id lj4mr9160318wjc.77.1423758837061; Thu, 12 Feb 2015 08:33:57 -0800 (PST) Received: by 10.27.84.148 with HTTP; Thu, 12 Feb 2015 08:33:57 -0800 (PST) In-Reply-To: <01b401d045f5$d5a1d000$4001a8c0@gateway.2wire.net> References: <01b401d045f5$d5a1d000$4001a8c0@gateway.2wire.net> Date: Thu, 12 Feb 2015 20:33:57 +0400 Message-ID: From: Mohamad Badra To: "t.petch" Content-Type: multipart/alternative; boundary=047d7b873d46ba9ff5050ee6af60 Archived-At: Cc: Netconf Subject: Re: [Netconf] IPR Poll for draft-ietf-netconf-rfc5539bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 16:34:00 -0000 --047d7b873d46ba9ff5050ee6af60 Content-Type: text/plain; charset=ISO-8859-1 Dear All, I am not aware of any IPR that applies to draft-ietf-netconf-rfc5539bis- 08.txt Best regards Badra On Wed, Feb 11, 2015 at 4:24 PM, t.petch wrote: > I don't know if I have contributed anything to this I-D or not - it has > changed so much over the years - but if I have, I know of no IPR > relating to my contributions. > > Tom Petch > > > ----- Original Message ----- > From: "Mahesh Jethanandani" > To: "Netconf" > Sent: Monday, February 09, 2015 6:50 AM > > NETCONF WG: > > This mail starts the IPR poll on draft-ietf-netconf-rfc5539bis-08.txt. > > Are you aware of any IPR that applies to > draft-ietf-netconf-rfc5539bis-08.txt? > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs > 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this > email explicitly regardless of whether or not you are aware of any > relevant IPR. > *The response needs to be sent to the NETCONF wg mailing list.* The > document > will not advance to the next stage until a response has been received > from *each > author and contributor*. > > If you are on the NETCONF WG email list but are not listed as an author > or > contributor, then please explicitly respond only if you are aware of any > IPR that > has not yet been disclosed in conformance with IETF rules. > > Thanks. > > Mahesh and Mehmet > Chairs, NETCONF WG > > > > > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > 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 > --047d7b873d46ba9ff5050ee6af60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,
I am not aware of any IPR that applies to=A0draft-ietf-netconf-rfc5539bis-08.txt

Best regards
Badra

On Wed, Fe= b 11, 2015 at 4:24 PM, t.petch <ietfc@btconnect.com> wrote= :
I don't know if I have contributed = anything to this I-D or not - it has
changed so much over the years - but if I have, I know of no IPR
relating to my contributions.

Tom Petch


----- Original Message -----
From: "Mahesh Jethanandani" <mjethanandani@gmail.com>
To: "Netconf" <netconf@iet= f.org>
Sent: Monday, February 09, 2015 6:50 AM

NETCONF WG:

This mail starts the IPR poll on draft-ietf-netconf-rfc5539bis-08.txt.

Are you aware of any IPR that applies to
draft-ietf-netconf-rfc5539bis-08.txt?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs
3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to
this
email explicitly regardless of whether or not you are aware of any
relevant IPR.
*The response needs to be sent to the NETCONF wg mailing list.* The
document
will not advance to the next stage until a response has been received
from *each
author and contributor*.

If you are on the NETCONF WG email list but are not listed as an author
or
contributor, then please explicitly respond only if you are aware of any IPR that
has not yet been disclosed in conformance with IETF rules.

Thanks.

Mahesh and Mehmet
Chairs, NETCONF WG








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


> _______________________________________________
> 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

--047d7b873d46ba9ff5050ee6af60-- From nobody Thu Feb 12 16:46: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 66E5C1A026C for ; Thu, 12 Feb 2015 16:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mt6vdfyWool for ; Thu, 12 Feb 2015 16:46:03 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (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 E8A561A039B for ; Thu, 12 Feb 2015 16:46:02 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id j5so10998461qga.3 for ; Thu, 12 Feb 2015 16:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TvERH6wSmoZcP6KdkECh6mPtKSq7mYCkFiJP3MYuR2I=; b=OMdQsuDrtrjKqne2IUIkOvz/O1FQTk3JfTASCdIygVXxsxebhsSBxCAmLC4CY3HNhz wPmwB9PYPdTriq1VXr17dPxYVh60WQoH9nhcnJsF3O/jxqDbAVdbpKawrhRPbmEKqwQm lbBvO2RLawKo9/VQUM9ReIN7jQp9GSujnIkE9nkw5ZxF7QeHUbqMBA4X7CxoSphSmtWz HY97o9Km7qVKnLyOqyx8AIv/jzxl4YkC4myGRfhUohJYQMKYAg6X2CYsqqyLUMUwJ2iK K/UgcjBjCS+K6RktV9FbeVHH6D12G41ml5TmUsUMi5iow7QPnN1/uHe5A0C8y8h3D6i1 ecyQ== X-Received: by 10.140.102.82 with SMTP id v76mr16531037qge.32.1423788356374; Thu, 12 Feb 2015 16:45:56 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id w21sm5645137qgd.15.2015.02.12.16.45.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 16:45:55 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_CDC53DCD-B9AF-4D9C-A6EE-E7CAB2341592" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 12 Feb 2015 16:45:53 -0800 Message-Id: References: To: Netconf X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Netconf] Call for agenda items 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, 13 Feb 2015 00:46:05 -0000 --Apple-Mail=_CDC53DCD-B9AF-4D9C-A6EE-E7CAB2341592 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a call for agenda items for IETF 92 in Dallas in March. Please = provide topics that you would like to discuss in the meeting. We will = publish a draft agenda later in February. Cheers. Mahesh & Mehmet --Apple-Mail=_CDC53DCD-B9AF-4D9C-A6EE-E7CAB2341592 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
This is a call for agenda items for IETF = 92 in Dallas in March. Please provide topics that you would like to = discuss in the meeting. We will publish a draft agenda later in = February.

Cheers.

Mahesh & = Mehmet




= --Apple-Mail=_CDC53DCD-B9AF-4D9C-A6EE-E7CAB2341592-- From nobody Thu Feb 12 19:01:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9311A07BD for ; Thu, 12 Feb 2015 19:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q4biPCP0-MjD for ; Thu, 12 Feb 2015 19:01:45 -0800 (PST) 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 EB1441A02F1 for ; Thu, 12 Feb 2015 19:01:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPF69309; Fri, 13 Feb 2015 03:01:43 +0000 (GMT) Received: from SZXEML432-HUB.china.huawei.com (10.82.67.209) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Feb 2015 03:01:42 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.141]) by szxeml432-hub.china.huawei.com ([10.82.67.209]) with mapi id 14.03.0158.001; Fri, 13 Feb 2015 11:01:34 +0800 From: Rohit R Ranade To: "Alexander Clemm (alex)" , Phil Shafer , Kent Watsen Thread-Topic: [Netconf] Notification updation RFC 5277 Thread-Index: AdAdmGPAceznqgnXSje9O6PD47W4GwKspEggBix6hTAAAhGVgAAEnTcAAABOrgAAAoyFgAAC/EgAAAFgtoABgRO+gA== Date: Fri, 13 Feb 2015 03:01:34 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A671E3249@szxeml512-mbs.china.huawei.com> References: <201502051831.t15IVw5U056876@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.144.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 03:01:47 -0000 Hi, Is there any update on this ? Preferably a solution which does not invo= lve tearing down and bringing up a session will be welcome. The notifications lost during the time period for which the session is down= . A separate mechanism to be used to get them back and the subsequent handl= ing will make it very complicated. Kindly help. With Regards, Rohit -----Original Message----- From: Alexander Clemm (alex) [mailto:alex@cisco.com]=20 Sent: 06 February, 2015 00:41 To: Phil Shafer; Kent Watsen Cc: Rohit R Ranade; netconf@ietf.org Subject: RE: [Netconf] Notification updation RFC 5277 Stability is all good, assuming it can be reasonably adapted to requirement= s. The other side of the stability coin would be inflexibility.=20 The need to adjust subscriptions appears fairly reasonable; we are also see= ing this in conjunction with datastore-push. So, I for one would think it = reasonable to look into extensions to accommodate such. =20 --- Alex -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer Sent: Thursday, February 05, 2015 10:32 AM To: Kent Watsen Cc: Rohit R Ranade; netconf@ietf.org Subject: Re: [Netconf] Notification updation RFC 5277 Kent Watsen writes: >>Not with RFC 5277 - there is no delete-subscription in RFC 5277. >Poor man's delete: drop the underlying NETCONF session. ;^) >The assumption is >that there is a dedicated NETCONF session for each subscription (no=20 >interleaving). Using SSH channels, this can be a fairly cheap=20 >operation, reusing the same underlying SSH connection. If we could have made that assumption, the notification mechanism would hav= e been oh-so easy. Instead we designed for interleaving notifications and = s. I thing it's too late to start requiring that assumption (un= less we want to redesign notifications (which would be a great idea (except= for my previous comments re: stability and "done"-ness))). Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Feb 12 22:07:13 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F221A0AF1 for ; Thu, 12 Feb 2015 22:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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 sRvwdWaD5Foc for ; Thu, 12 Feb 2015 22:07:02 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FA11A07BE for ; Thu, 12 Feb 2015 22:07:01 -0800 (PST) Received: by iecrp18 with SMTP id rp18so2044528iec.1 for ; Thu, 12 Feb 2015 22:07:01 -0800 (PST) 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 :cc:content-type; bh=kOCx7aDRsluCZDcFfLWURLiYbax6Z3M5t5inNhe9pg0=; b=ZFxBCk0Hj2uwFH+nupnv+gX9ZoGk5c5uLpaDaw8sg66lzX0BQw/KaqbsAfuMKIT/vP iR2YsUUlE2ZjMvt7WTEhYr8U+dzrH/X88Csw8NqnGSPy7B9jURn/pQGEgjmJd4PPfuhf se289s/E7PIZ8jHD9ggsCPRDtJq1ggl63kKsErNYIkuFH01MRsuN2TjJQMMG4OVDlVZE MWIimTPRAHxQy9wb+yZUgwnq/QtAWkvT5zgW53CE3VApue9o9eTAIPHalwtwz6dfFcAx gLcjG/g6tBmP39leqrvk3yItrm7scJml1SrmgOdtlsLqWPhEMIMRtU7gAmM+b+V2DP+p xKxg== MIME-Version: 1.0 X-Received: by 10.107.15.156 with SMTP id 28mr9812142iop.57.1423807621436; Thu, 12 Feb 2015 22:07:01 -0800 (PST) Received: by 10.36.0.15 with HTTP; Thu, 12 Feb 2015 22:07:01 -0800 (PST) In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671E3249@szxeml512-mbs.china.huawei.com> References: <201502051831.t15IVw5U056876@idle.juniper.net> <991B70D8B4112A4699D5C00DDBBF878A671E3249@szxeml512-mbs.china.huawei.com> Date: Fri, 13 Feb 2015 11:37:01 +0530 Message-ID: From: Ambika Tripathy To: Rohit R Ranade Content-Type: multipart/alternative; boundary=001a113edada811b6a050ef20b36 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 06:07:07 -0000 --001a113edada811b6a050ef20b36 Content-Type: text/plain; charset=UTF-8 Hi, The existing NetConf session with notification definition as per rfc5277 is very limited to just once subscription for all event in the system. For different filters in notification, there is a need to create different session and with unique subscription request. This is not a efficient solution. The mechanism should allow multiple unique create-subscription request in a session and send the event data based on subscription request and the subscription should be uniquely identified by one subscription-id for easy management like RPC, RPC-reply. The current way of handling notification is very limited to PUB-SUB mechanism also and not efficient solution. If there will be one extension to notification mechanism to handle PUB-SUB data, by addressing all requirements of datastore-push will help a lot. br, Ambika Prasad Tripathy On Fri, Feb 13, 2015 at 8:31 AM, Rohit R Ranade wrote: > Hi, Is there any update on this ? Preferably a solution which does not > involve tearing down and bringing up a session will be welcome. > The notifications lost during the time period for which the session is > down. A separate mechanism to be used to get them back and the subsequent > handling will make it very complicated. > Kindly help. > > With Regards, > Rohit > > -----Original Message----- > From: Alexander Clemm (alex) [mailto:alex@cisco.com] > Sent: 06 February, 2015 00:41 > To: Phil Shafer; Kent Watsen > Cc: Rohit R Ranade; netconf@ietf.org > Subject: RE: [Netconf] Notification updation RFC 5277 > > Stability is all good, assuming it can be reasonably adapted to > requirements. The other side of the stability coin would be inflexibility. > The need to adjust subscriptions appears fairly reasonable; we are also > seeing this in conjunction with datastore-push. So, I for one would think > it reasonable to look into extensions to accommodate such. > --- Alex > > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer > Sent: Thursday, February 05, 2015 10:32 AM > To: Kent Watsen > Cc: Rohit R Ranade; netconf@ietf.org > Subject: Re: [Netconf] Notification updation RFC 5277 > > Kent Watsen writes: > >>Not with RFC 5277 - there is no delete-subscription in RFC 5277. > >Poor man's delete: drop the underlying NETCONF session. > > ;^) > > >The assumption is > >that there is a dedicated NETCONF session for each subscription (no > >interleaving). Using SSH channels, this can be a fairly cheap > >operation, reusing the same underlying SSH connection. > > If we could have made that assumption, the notification mechanism would > have been oh-so easy. Instead we designed for interleaving notifications > and s. I thing it's too late to start requiring that assumption > (unless we want to redesign notifications (which would be a great idea > (except for my previous comments re: > stability and "done"-ness))). > > Thanks, > Phil > > _______________________________________________ > 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 > -- Ambika Prasad Tripathy Cell @+91 9437547730/8553070866 Alt email: ambika_tripathy@yahoo.com ambika.tripathy@gmail.com skype:ambika_nethawk --001a113edada811b6a050ef20b36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, The existing NetConf session with notification definit= ion as per rfc5277 is very limited to just once subscription for all event = in the system. For different filters in notification, there is a need to cr= eate different session and with unique subscription request. This is not a = efficient solution.=C2=A0
The mechanism should allow multiple unique cr= eate-subscription request in a session and send the event data based on sub= scription request and the subscription should =C2=A0be uniquely identified = by one subscription-id for easy management like RPC, RPC-reply.=C2=A0
<= br>
The current way of handling notification is very limited to PUB-SUB= mechanism also and not efficient solution. If there will be one extension = to notification mechanism to handle PUB-SUB data, by addressing all require= ments of datastore-push will help a lot.

br,
Ambika Prasad Tripathy

On Fri, Feb 13, 2015 at 8:31 AM, Rohit R = Ranade <rohitrranade@huawei.com> wrote:
Hi, Is there any update on this ? Preferably a solution= which does not involve tearing down and bringing up a session will be welc= ome.
The notifications lost during the time period for which the session is down= . A separate mechanism to be used to get them back and the subsequent handl= ing will make it very complicated.
Kindly help.

With Regards,
Rohit

-----Original Message-----
From: Alexander Clemm (alex) [mailto:alex= @cisco.com]
Sent: 06 February, 2015 00:41
To: Phil Shafer; Kent Watsen
Cc: Rohit R Ranade; netconf@ietf.org
Subject: RE: [Netconf] Notif= ication updation RFC 5277

Stability is all good, assuming it can be reasonably adapted to requirement= s.=C2=A0 The other side of the stability coin would be inflexibility.
The need to adjust subscriptions appears fairly reasonable; we are also see= ing this in conjunction with datastore-push.=C2=A0 So, I for one would thin= k it reasonable to look into extensions to accommodate such.
--- Alex


-----Original Message-----
From: Netconf [mailto:netconf-b= ounces@ietf.org] On Behalf Of Phil Shafer
Sent: Thursday, February 05, 2015 10:32 AM
To: Kent Watsen
Cc: Rohit R Ranade; netconf@ietf.org
Subject: Re: [Netconf] Notification updation RFC 5277

Kent Watsen writes:
>>Not with RFC 5277 - there is no delete-subscription in RFC 5277. >Poor man's delete: drop the underlying NETCONF session.

;^)

>The assumption is
>that there is a dedicated NETCONF session for each subscription (no
>interleaving).=C2=A0 Using SSH channels, this can be a fairly cheap
>operation, reusing the same underlying SSH connection.

If we could have made that assumption, the notification mechanism would hav= e been oh-so easy.=C2=A0 Instead we designed for interleaving notifications= and <rpc-reply>s.=C2=A0 I thing it's too late to start requiring= that assumption (unless we want to redesign notifications (which would be = a great idea (except for my previous comments re:
stability and "done"-ness))).

Thanks,
=C2=A0Phil

_______________________________________________
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



--
=
Ambika Prasad Tripathy=
Cell @+91 9437547730/8553070866
skype:ambika_nethawk
--001a113edada811b6a050ef20b36-- From nobody Thu Feb 12 22: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 DEA0A1A1A27 for ; Thu, 12 Feb 2015 22:54:12 -0800 (PST) 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 U7lU4QGCb4_3 for ; Thu, 12 Feb 2015 22:54:09 -0800 (PST) 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 C29961A1AF6 for ; Thu, 12 Feb 2015 22:54:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPF83384; Fri, 13 Feb 2015 06:54:06 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Feb 2015 06:54:06 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.141]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0158.001; Fri, 13 Feb 2015 14:53:57 +0800 From: Rohit R Ranade To: Ambika Tripathy Thread-Topic: [Netconf] Notification updation RFC 5277 Thread-Index: AdAdmGPAceznqgnXSje9O6PD47W4GwKspEggBix6hTAAAhGVgAAEnTcAAABOrgAAAoyFgAAC/EgAAAFgtoABgRO+gP//ruCA//9t0yA= Date: Fri, 13 Feb 2015 06:53:56 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A671E3262@szxeml512-mbs.china.huawei.com> References: <201502051831.t15IVw5U056876@idle.juniper.net> <991B70D8B4112A4699D5C00DDBBF878A671E3249@szxeml512-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.144.92] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A671E3262szxeml512mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 06:54:13 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A671E3262szxeml512mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIHBlciB5b3VyIG1haWwgYWJvdXQgRGF0YXN0b3JlLXB1c2gsIEkgcmVmZXJyZWQg dG8gdGhlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uZXRtb2QtY2xlbW0tZGF0 YXN0b3JlLXB1c2gtMDAgZHJhZnQgb2YgZGF0YXN0b3JlLXB1c2guDQpLaW5kbHkgcHJvdmlkZSB0 aGUgcmVxdWlyZW1lbnRzIG9mIGRhdGEtc3RvcmUtcHVzaCB0aGF0IG5lZWRzIHRvIGJlIGFkZGVk KCB0aGF0IHlvdSBjdXJyZW50bHkgaGF2ZSBpbiBtaW5kZWQpIHRvIHRoZSBleHRlbnNpb24uIEkg aGF2ZSBhIHNjZW5hcmlvLCB3aGVyZSBtYXliZSBkYXRhc3RvcmUtcHVzaCBhbHNvIG1pZ2h0IGJl IG5lY2Vzc2FyeSBmb3IgbXkgY2xpZW50Lg0KTWF5YmUgYmFzZWQgb24geW91ciB0aG91Z2h0cyBt YXliZSBJIGNhbiBhbHNvIGFkZCB0byB0aG9zZSByZXF1aXJlbWVudHMuDQoNCldpdGggUmVnYXJk cywNClJvaGl0DQoNCkZyb206IEFtYmlrYSBUcmlwYXRoeSBbbWFpbHRvOmFtYmlrYS50cmlwYXRo eUBnbWFpbC5jb21dDQpTZW50OiAxMyBGZWJydWFyeSwgMjAxNSAxMTozNw0KVG86IFJvaGl0IFIg UmFuYWRlDQpDYzogQWxleGFuZGVyIENsZW1tIChhbGV4KTsgUGhpbCBTaGFmZXI7IEtlbnQgV2F0 c2VuOyBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIE5vdGlmaWNhdGlv biB1cGRhdGlvbiBSRkMgNTI3Nw0KDQpIaSwgVGhlIGV4aXN0aW5nIE5ldENvbmYgc2Vzc2lvbiB3 aXRoIG5vdGlmaWNhdGlvbiBkZWZpbml0aW9uIGFzIHBlciByZmM1Mjc3IGlzIHZlcnkgbGltaXRl ZCB0byBqdXN0IG9uY2Ugc3Vic2NyaXB0aW9uIGZvciBhbGwgZXZlbnQgaW4gdGhlIHN5c3RlbS4g Rm9yIGRpZmZlcmVudCBmaWx0ZXJzIGluIG5vdGlmaWNhdGlvbiwgdGhlcmUgaXMgYSBuZWVkIHRv IGNyZWF0ZSBkaWZmZXJlbnQgc2Vzc2lvbiBhbmQgd2l0aCB1bmlxdWUgc3Vic2NyaXB0aW9uIHJl cXVlc3QuIFRoaXMgaXMgbm90IGEgZWZmaWNpZW50IHNvbHV0aW9uLg0KVGhlIG1lY2hhbmlzbSBz aG91bGQgYWxsb3cgbXVsdGlwbGUgdW5pcXVlIGNyZWF0ZS1zdWJzY3JpcHRpb24gcmVxdWVzdCBp biBhIHNlc3Npb24gYW5kIHNlbmQgdGhlIGV2ZW50IGRhdGEgYmFzZWQgb24gc3Vic2NyaXB0aW9u IHJlcXVlc3QgYW5kIHRoZSBzdWJzY3JpcHRpb24gc2hvdWxkICBiZSB1bmlxdWVseSBpZGVudGlm aWVkIGJ5IG9uZSBzdWJzY3JpcHRpb24taWQgZm9yIGVhc3kgbWFuYWdlbWVudCBsaWtlIFJQQywg UlBDLXJlcGx5Lg0KDQpUaGUgY3VycmVudCB3YXkgb2YgaGFuZGxpbmcgbm90aWZpY2F0aW9uIGlz IHZlcnkgbGltaXRlZCB0byBQVUItU1VCIG1lY2hhbmlzbSBhbHNvIGFuZCBub3QgZWZmaWNpZW50 IHNvbHV0aW9uLiBJZiB0aGVyZSB3aWxsIGJlIG9uZSBleHRlbnNpb24gdG8gbm90aWZpY2F0aW9u IG1lY2hhbmlzbSB0byBoYW5kbGUgUFVCLVNVQiBkYXRhLCBieSBhZGRyZXNzaW5nIGFsbCByZXF1 aXJlbWVudHMgb2YgZGF0YXN0b3JlLXB1c2ggd2lsbCBoZWxwIGEgbG90Lg0KDQpiciwNCkFtYmlr YSBQcmFzYWQgVHJpcGF0aHkNCg0KT24gRnJpLCBGZWIgMTMsIDIwMTUgYXQgODozMSBBTSwgUm9o aXQgUiBSYW5hZGUgPHJvaGl0cnJhbmFkZUBodWF3ZWkuY29tPG1haWx0bzpyb2hpdHJyYW5hZGVA aHVhd2VpLmNvbT4+IHdyb3RlOg0KSGksIElzIHRoZXJlIGFueSB1cGRhdGUgb24gdGhpcyA/IFBy ZWZlcmFibHkgYSBzb2x1dGlvbiB3aGljaCBkb2VzIG5vdCBpbnZvbHZlIHRlYXJpbmcgZG93biBh bmQgYnJpbmdpbmcgdXAgYSBzZXNzaW9uIHdpbGwgYmUgd2VsY29tZS4NClRoZSBub3RpZmljYXRp b25zIGxvc3QgZHVyaW5nIHRoZSB0aW1lIHBlcmlvZCBmb3Igd2hpY2ggdGhlIHNlc3Npb24gaXMg ZG93bi4gQSBzZXBhcmF0ZSBtZWNoYW5pc20gdG8gYmUgdXNlZCB0byBnZXQgdGhlbSBiYWNrIGFu ZCB0aGUgc3Vic2VxdWVudCBoYW5kbGluZyB3aWxsIG1ha2UgaXQgdmVyeSBjb21wbGljYXRlZC4N CktpbmRseSBoZWxwLg0KDQpXaXRoIFJlZ2FyZHMsDQpSb2hpdA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQWxleGFuZGVyIENsZW1tIChhbGV4KSBbbWFpbHRvOmFsZXhAY2lz Y28uY29tPG1haWx0bzphbGV4QGNpc2NvLmNvbT5dDQpTZW50OiAwNiBGZWJydWFyeSwgMjAxNSAw MDo0MQ0KVG86IFBoaWwgU2hhZmVyOyBLZW50IFdhdHNlbg0KQ2M6IFJvaGl0IFIgUmFuYWRlOyBu ZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtO ZXRjb25mXSBOb3RpZmljYXRpb24gdXBkYXRpb24gUkZDIDUyNzcNCg0KU3RhYmlsaXR5IGlzIGFs bCBnb29kLCBhc3N1bWluZyBpdCBjYW4gYmUgcmVhc29uYWJseSBhZGFwdGVkIHRvIHJlcXVpcmVt ZW50cy4gIFRoZSBvdGhlciBzaWRlIG9mIHRoZSBzdGFiaWxpdHkgY29pbiB3b3VsZCBiZSBpbmZs ZXhpYmlsaXR5Lg0KVGhlIG5lZWQgdG8gYWRqdXN0IHN1YnNjcmlwdGlvbnMgYXBwZWFycyBmYWly bHkgcmVhc29uYWJsZTsgd2UgYXJlIGFsc28gc2VlaW5nIHRoaXMgaW4gY29uanVuY3Rpb24gd2l0 aCBkYXRhc3RvcmUtcHVzaC4gIFNvLCBJIGZvciBvbmUgd291bGQgdGhpbmsgaXQgcmVhc29uYWJs ZSB0byBsb29rIGludG8gZXh0ZW5zaW9ucyB0byBhY2NvbW1vZGF0ZSBzdWNoLg0KLS0tIEFsZXgN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5l dGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIFBoaWwgU2hhZmVyDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDUsIDIw MTUgMTA6MzIgQU0NClRvOiBLZW50IFdhdHNlbg0KQ2M6IFJvaGl0IFIgUmFuYWRlOyBuZXRjb25m QGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtOZXRjb25m XSBOb3RpZmljYXRpb24gdXBkYXRpb24gUkZDIDUyNzcNCg0KS2VudCBXYXRzZW4gd3JpdGVzOg0K Pj5Ob3Qgd2l0aCBSRkMgNTI3NyAtIHRoZXJlIGlzIG5vIGRlbGV0ZS1zdWJzY3JpcHRpb24gaW4g UkZDIDUyNzcuDQo+UG9vciBtYW4ncyBkZWxldGU6IGRyb3AgdGhlIHVuZGVybHlpbmcgTkVUQ09O RiBzZXNzaW9uLg0KDQo7XikNCg0KPlRoZSBhc3N1bXB0aW9uIGlzDQo+dGhhdCB0aGVyZSBpcyBh IGRlZGljYXRlZCBORVRDT05GIHNlc3Npb24gZm9yIGVhY2ggc3Vic2NyaXB0aW9uIChubw0KPmlu dGVybGVhdmluZykuICBVc2luZyBTU0ggY2hhbm5lbHMsIHRoaXMgY2FuIGJlIGEgZmFpcmx5IGNo ZWFwDQo+b3BlcmF0aW9uLCByZXVzaW5nIHRoZSBzYW1lIHVuZGVybHlpbmcgU1NIIGNvbm5lY3Rp b24uDQoNCklmIHdlIGNvdWxkIGhhdmUgbWFkZSB0aGF0IGFzc3VtcHRpb24sIHRoZSBub3RpZmlj YXRpb24gbWVjaGFuaXNtIHdvdWxkIGhhdmUgYmVlbiBvaC1zbyBlYXN5LiAgSW5zdGVhZCB3ZSBk ZXNpZ25lZCBmb3IgaW50ZXJsZWF2aW5nIG5vdGlmaWNhdGlvbnMgYW5kIDxycGMtcmVwbHk+cy4g IEkgdGhpbmcgaXQncyB0b28gbGF0ZSB0byBzdGFydCByZXF1aXJpbmcgdGhhdCBhc3N1bXB0aW9u ICh1bmxlc3Mgd2Ugd2FudCB0byByZWRlc2lnbiBub3RpZmljYXRpb25zICh3aGljaCB3b3VsZCBi ZSBhIGdyZWF0IGlkZWEgKGV4Y2VwdCBmb3IgbXkgcHJldmlvdXMgY29tbWVudHMgcmU6DQpzdGFi aWxpdHkgYW5kICJkb25lIi1uZXNzKSkpLg0KDQpUaGFua3MsDQogUGhpbA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxp c3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRj b25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg0KDQotLQ0KQW1iaWthIFByYXNhZCBUcmlw YXRoeQ0KQ2VsbCBAKzkxIDk0Mzc1NDc3MzAvODU1MzA3MDg2Ng0KQWx0IGVtYWlsOiBhbWJpa2Ff dHJpcGF0aHlAeWFob28uY29tPG1haWx0bzphbWJpa2FfdHJpcGF0aHlAeWFob28uY29tPg0KYW1i aWthLnRyaXBhdGh5QGdtYWlsLmNvbTxtYWlsdG86YW1iaWthLnRyaXBhdGh5QGdtYWlsLmNvbT4N CnNreXBlOmFtYmlrYV9uZXRoYXdrDQo= --_000_991B70D8B4112A4699D5C00DDBBF878A671E3262szxeml512mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u aW0NCgl7bXNvLXN0eWxlLW5hbWU6aW07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIHBlciB5b3VyIG1haWwgYWJvdXQgRGF0YXN0b3JlLXB1c2gs IEkgcmVmZXJyZWQgdG8gdGhlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbmV0bW9kLWNsZW1tLWRhdGFzdG9yZS1wdXNoLTAwIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbmV0bW9kLWNsZW1tLWRhdGFzdG9yZS1wdXNoLTAwPC9hPiBkcmFmdCBv ZiBkYXRhc3RvcmUtcHVzaC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5LaW5kbHkg cHJvdmlkZSB0aGUgcmVxdWlyZW1lbnRzIG9mIGRhdGEtc3RvcmUtcHVzaCB0aGF0IG5lZWRzIHRv IGJlIGFkZGVkKCB0aGF0IHlvdSBjdXJyZW50bHkgaGF2ZSBpbiBtaW5kZWQpIHRvIHRoZSBleHRl bnNpb24uIEkgaGF2ZSBhIHNjZW5hcmlvLCB3aGVyZSBtYXliZQ0KIGRhdGFzdG9yZS1wdXNoIGFs c28gbWlnaHQgYmUgbmVjZXNzYXJ5IGZvciBteSBjbGllbnQuIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5NYXliZSBiYXNlZCBvbiB5b3VyIHRob3VnaHRzIG1heWJlIEkgY2FuIGFsc28g YWRkIHRvIHRob3NlIHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldpdGggUmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9oaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFtYmlrYSBUcmlwYXRo eSBbbWFpbHRvOmFtYmlrYS50cmlwYXRoeUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g MTMgRmVicnVhcnksIDIwMTUgMTE6Mzc8YnI+DQo8Yj5Ubzo8L2I+IFJvaGl0IFIgUmFuYWRlPGJy Pg0KPGI+Q2M6PC9iPiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBQaGlsIFNoYWZlcjsgS2VudCBX YXRzZW47IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25m XSBOb3RpZmljYXRpb24gdXBkYXRpb24gUkZDIDUyNzc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBUaGUgZXhpc3RpbmcgTmV0Q29uZiBzZXNzaW9uIHdp dGggbm90aWZpY2F0aW9uIGRlZmluaXRpb24gYXMgcGVyIHJmYzUyNzcgaXMgdmVyeSBsaW1pdGVk IHRvIGp1c3Qgb25jZSBzdWJzY3JpcHRpb24gZm9yIGFsbCBldmVudCBpbiB0aGUgc3lzdGVtLiBG b3IgZGlmZmVyZW50IGZpbHRlcnMgaW4gbm90aWZpY2F0aW9uLCB0aGVyZSBpcyBhIG5lZWQgdG8g Y3JlYXRlIGRpZmZlcmVudCBzZXNzaW9uIGFuZCB3aXRoDQogdW5pcXVlIHN1YnNjcmlwdGlvbiBy ZXF1ZXN0LiBUaGlzIGlzIG5vdCBhIGVmZmljaWVudCBzb2x1dGlvbi4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbWVjaGFuaXNtIHNob3VsZCBh bGxvdyBtdWx0aXBsZSB1bmlxdWUgY3JlYXRlLXN1YnNjcmlwdGlvbiByZXF1ZXN0IGluIGEgc2Vz c2lvbiBhbmQgc2VuZCB0aGUgZXZlbnQgZGF0YSBiYXNlZCBvbiBzdWJzY3JpcHRpb24gcmVxdWVz dCBhbmQgdGhlIHN1YnNjcmlwdGlvbiBzaG91bGQgJm5ic3A7YmUgdW5pcXVlbHkgaWRlbnRpZmll ZCBieSBvbmUgc3Vic2NyaXB0aW9uLWlkIGZvciBlYXN5IG1hbmFnZW1lbnQgbGlrZQ0KIFJQQywg UlBDLXJlcGx5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBjdXJyZW50IHdheSBvZiBoYW5kbGluZyBub3RpZmljYXRpb24gaXMgdmVyeSBsaW1pdGVkIHRv IFBVQi1TVUIgbWVjaGFuaXNtIGFsc28gYW5kIG5vdCBlZmZpY2llbnQgc29sdXRpb24uIElmIHRo ZXJlIHdpbGwgYmUgb25lIGV4dGVuc2lvbiB0byBub3RpZmljYXRpb24gbWVjaGFuaXNtIHRvIGhh bmRsZSBQVUItU1VCIGRhdGEsIGJ5IGFkZHJlc3NpbmcgYWxsIHJlcXVpcmVtZW50cyBvZiBkYXRh c3RvcmUtcHVzaA0KIHdpbGwgaGVscCBhIGxvdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJyLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW1iaWthIFByYXNhZCBU cmlwYXRoeTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBGcmksIEZlYiAxMywgMjAxNSBhdCA4OjMxIEFNLCBSb2hpdCBSIFJhbmFkZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvaGl0cnJhbmFkZUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ cm9oaXRycmFuYWRlQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBJcyB0aGVyZSBhbnkgdXBkYXRlIG9uIHRoaXMgPyBQcmVm ZXJhYmx5IGEgc29sdXRpb24gd2hpY2ggZG9lcyBub3QgaW52b2x2ZSB0ZWFyaW5nIGRvd24gYW5k IGJyaW5naW5nIHVwIGEgc2Vzc2lvbiB3aWxsIGJlIHdlbGNvbWUuPGJyPg0KVGhlIG5vdGlmaWNh dGlvbnMgbG9zdCBkdXJpbmcgdGhlIHRpbWUgcGVyaW9kIGZvciB3aGljaCB0aGUgc2Vzc2lvbiBp cyBkb3duLiBBIHNlcGFyYXRlIG1lY2hhbmlzbSB0byBiZSB1c2VkIHRvIGdldCB0aGVtIGJhY2sg YW5kIHRoZSBzdWJzZXF1ZW50IGhhbmRsaW5nIHdpbGwgbWFrZSBpdCB2ZXJ5IGNvbXBsaWNhdGVk Ljxicj4NCktpbmRseSBoZWxwLjxicj4NCjxicj4NCldpdGggUmVnYXJkcyw8YnI+DQpSb2hpdDxi cj4NCjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L3Nw YW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5Gcm9tOiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmFsZXhAY2lzY28uY29tIj5hbGV4QGNpc2NvLmNvbTwvYT5d PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+U2VudDogMDYgRmVicnVhcnksIDIwMTUgMDA6 NDE8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5UbzogUGhpbCBTaGFmZXI7IEtlbnQgV2F0 c2VuPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Q2M6IFJvaGl0IFIgUmFuYWRlOyA8YSBo cmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1Ympl Y3Q6IFJFOiBbTmV0Y29uZl0gTm90aWZpY2F0aW9uIHVwZGF0aW9uIFJGQyA1Mjc3PGJyPg0KPGJy Pg0KU3RhYmlsaXR5IGlzIGFsbCBnb29kLCBhc3N1bWluZyBpdCBjYW4gYmUgcmVhc29uYWJseSBh ZGFwdGVkIHRvIHJlcXVpcmVtZW50cy4mbmJzcDsgVGhlIG90aGVyIHNpZGUgb2YgdGhlIHN0YWJp bGl0eSBjb2luIHdvdWxkIGJlIGluZmxleGliaWxpdHkuPGJyPg0KVGhlIG5lZWQgdG8gYWRqdXN0 IHN1YnNjcmlwdGlvbnMgYXBwZWFycyBmYWlybHkgcmVhc29uYWJsZTsgd2UgYXJlIGFsc28gc2Vl aW5nIHRoaXMgaW4gY29uanVuY3Rpb24gd2l0aCBkYXRhc3RvcmUtcHVzaC4mbmJzcDsgU28sIEkg Zm9yIG9uZSB3b3VsZCB0aGluayBpdCByZWFzb25hYmxlIHRvIGxvb2sgaW50byBleHRlbnNpb25z IHRvIGFjY29tbW9kYXRlIHN1Y2guPGJyPg0KLS0tIEFsZXg8YnI+DQo8YnI+DQo8YnI+DQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IE5ldGNvbmYgW21haWx0bzo8YSBocmVm PSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj5uZXRjb25mLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSBPbiBCZWhhbGYgT2YgUGhpbCBTaGFmZXI8YnI+DQpTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgMDUsIDIwMTUgMTA6MzIgQU08YnI+DQpUbzogS2VudCBXYXRzZW48YnI+DQpDYzogUm9o aXQgUiBSYW5hZGU7IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGll dGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gTm90aWZpY2F0aW9uIHVwZGF0 aW9uIFJGQyA1Mjc3PGJyPg0KPGJyPg0KS2VudCBXYXRzZW4gd3JpdGVzOjxicj4NCiZndDsmZ3Q7 Tm90IHdpdGggUkZDIDUyNzcgLSB0aGVyZSBpcyBubyBkZWxldGUtc3Vic2NyaXB0aW9uIGluIFJG QyA1Mjc3Ljxicj4NCiZndDtQb29yIG1hbidzIGRlbGV0ZTogZHJvcCB0aGUgdW5kZXJseWluZyBO RVRDT05GIHNlc3Npb24uPGJyPg0KPGJyPg0KO14pPGJyPg0KPGJyPg0KJmd0O1RoZSBhc3N1bXB0 aW9uIGlzPGJyPg0KJmd0O3RoYXQgdGhlcmUgaXMgYSBkZWRpY2F0ZWQgTkVUQ09ORiBzZXNzaW9u IGZvciBlYWNoIHN1YnNjcmlwdGlvbiAobm88YnI+DQomZ3Q7aW50ZXJsZWF2aW5nKS4mbmJzcDsg VXNpbmcgU1NIIGNoYW5uZWxzLCB0aGlzIGNhbiBiZSBhIGZhaXJseSBjaGVhcDxicj4NCiZndDtv cGVyYXRpb24sIHJldXNpbmcgdGhlIHNhbWUgdW5kZXJseWluZyBTU0ggY29ubmVjdGlvbi48YnI+ DQo8YnI+DQpJZiB3ZSBjb3VsZCBoYXZlIG1hZGUgdGhhdCBhc3N1bXB0aW9uLCB0aGUgbm90aWZp Y2F0aW9uIG1lY2hhbmlzbSB3b3VsZCBoYXZlIGJlZW4gb2gtc28gZWFzeS4mbmJzcDsgSW5zdGVh ZCB3ZSBkZXNpZ25lZCBmb3IgaW50ZXJsZWF2aW5nIG5vdGlmaWNhdGlvbnMgYW5kICZsdDtycGMt cmVwbHkmZ3Q7cy4mbmJzcDsgSSB0aGluZyBpdCdzIHRvbyBsYXRlIHRvIHN0YXJ0IHJlcXVpcmlu ZyB0aGF0IGFzc3VtcHRpb24gKHVubGVzcyB3ZSB3YW50IHRvIHJlZGVzaWduIG5vdGlmaWNhdGlv bnMNCiAod2hpY2ggd291bGQgYmUgYSBncmVhdCBpZGVhIChleGNlcHQgZm9yIG15IHByZXZpb3Vz IGNvbW1lbnRzIHJlOjxicj4NCnN0YWJpbGl0eSBhbmQgJnF1b3Q7ZG9uZSZxdW90Oy1uZXNzKSkp Ljxicj4NCjxicj4NClRoYW5rcyw8YnI+DQombmJzcDtQaGlsPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW1iaWthIFByYXNhZCBUcmlwYXRoeTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2VsbCBAJiM0Mzs5 MSA5NDM3NTQ3NzMwLzg1NTMwNzA4NjY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFsdCBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmFtYmlrYV90cmlw YXRoeUB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmFtYmlrYV90cmlwYXRoeUB5YWhvby5j b208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBocmVmPSJtYWlsdG86YW1iaWthLnRyaXBhdGh5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmFtYmlrYS50cmlwYXRoeUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5za3lwZTphbWJpa2FfbmV0aGF3azxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_991B70D8B4112A4699D5C00DDBBF878A671E3262szxeml512mbschi_-- From nobody Fri Feb 13 08:22:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAFB1A876D for ; Fri, 13 Feb 2015 08:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t955qCW-BFGr for ; Fri, 13 Feb 2015 08:22:28 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACEF1A8757 for ; Fri, 13 Feb 2015 08:22:20 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t1DGMGGk027495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Feb 2015 16:22:16 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t1DGMDlA012309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Feb 2015 17:22:14 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 13 Feb 2015 17:22:13 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 17:22:13 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Update of Charter Deadlines WAS:RE: [Netconf] Call for Adoption of two new WG Items splitted from RESTCONF Thread-Index: AdA/F6IgNKjf8JhMQPOJlQJ4Uu0cbgAZqemAAAo09lAB/m5TsA== Date: Fri, 13 Feb 2015 16:22:12 +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.110] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81962510ADEMUMBX005nsnin_" 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: 43674 X-purgate-ID: 151667::1423844536-000067C4-6F3D73AE/0/0 Archived-At: Subject: [Netconf] Update of Charter Deadlines WAS:RE: Call for Adoption of two new WG Items splitted from RESTCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 16:22:34 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81962510ADEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, below is the updated timeline for NETCONF WG items agreed with our AD inclu= ding the new drafts adopted recently. As the new drafts are only a split from RESTCONF, an update of the WG chart= er text is not necessary. Done - WGLC for RFC5539bis Feb 2015 - WGLC for RESTCONF and patch operation drafts Mar 2015 - WGLC for RESTCONF YANG Library Mar 2015 - WGLC for NETCONF call home mechanism Mar 2015 - WGLC for NETCONF server configuration data model May 2015 - WGLC for RESTCONF Collection May 2015 - WGLC for zero touch configuration Feb 2015 - Submit RFC5539bis to AD/IESG for consideration as Proposed Sta= ndard Apr 2015 - Submit RESTCONF and YANG patch operation to AD/IESG for consid= eration as Proposed Standard Apr 2015 - Submit RESTCONF YANG Library to AD/IESG for consideration as P= roposed Standard Apr 2015 - Submit NETCONF call home mechanism to AD/IESG for consideratio= n as Proposed Standard Apr 2015 - Submit server configuration data model to AD/IESG for consider= ation as Proposed Standard Jun 2015 - Submit RESTCONF Collection to AD/IESG for consideration as Prop= osed Standard Jun 2015 - Submit zero touch configuration to AD/IESG for consideration a= s Proposed Standard These deadlines have been now entered into datatracker page for milestones. https://datatracker.ietf.org/wg/netconf/milestones/ Best Regards, Mehmet & Mahesh From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Tuesday, February 03, 2015 12:56 PM To: netconf@ietf.org Subject: [Netconf] Call for Adoption of two new WG Items splitted from REST= CONF Dear NETCONF WG, providing Restconf Collection and YANG library as separate drafts has been = proposed as part of the Restconf issue solving (issues #3 and #13). The iss= ues were in VERIFY state some time without objection. As such we assume alr= eady some agreement for the separation. Restconf Collection and YANG library have been now provided as two separate= drafts: https://tools.ietf.org/html/draft-ietf-netconf-restconf-collection-00 https://tools.ietf.org/html/draft-ietf-netconf-yang-library-00 After checking with our AD Benoit, this is the final WG call for the adopti= on of the two drafts above as WG item documents, with a shorted deadline fo= r 4 business days. If there is no strong objection by February 9, 2015 EOB PT, the co-chairs w= ill work with our AD to update the charter deliverables (as the current cha= rter covers Restconf and there is no additional feature in these drafts, th= e charter text will not be changed). @All: Please upload documents in the future as draft-ietf-netconf only afte= r checking with the co-chairs and the approval of the charter update. Best Regards, Mehmet & Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F81962510ADEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= All,

=  

= below is the updated timeline for NETCONF WG items agreed with our AD including the new drafts adopted recently. <= /o:p>

= As the new drafts are only a split from RESTCONF= , an update of the WG charter text is not necessary.

=  

  Done - WGLC for RFC5539bis

 

  Feb 2015 - WGLC for RESTCONF and patch operation drafts

  Mar 2015 - WGLC for RESTCONF YANG Library

  Mar 2015 - WGLC for NETCONF call home mechanism

  Mar 2015 - WGLC for NETCONF server configuration data model

  May 2015 - WGLC for RESTCONF Collection

  May 2015 - WGLC for zero touch configuration

 =

  Feb 2015 - Submit RFC5539bis to AD/IESG for consideration as Propose= d Standard

  Apr 2015 - Submit RESTCONF and YANG patch operation to AD/IESG for c= onsideration as Proposed Standard

  Apr 2015 - Submit RESTCONF YANG Library to AD/IESG for consideration= as Proposed Standard

  Apr 2015 - Submit NETCONF call home mechanism to AD/IESG for conside= ration as Proposed Standard

  Apr 2015 - Submit server configuration data model to AD/IESG for con= sideration as Proposed Standard

 Jun 2015 - Submit RESTCONF Collection to AD/= IESG for consideration as Proposed Standard=

  Jun 2015 - Submit zero touch configuration to AD/IESG for considerat= ion as Proposed Standard

=  

= These deadlines have been now entered into datatracker page for milestones.

= https://datatracker.ietf.org/wg/netconf/milestones/

=  

= Best Regards,
Mehmet & Mahesh

=  

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Ersue, Mehm= et (NSN - DE/Munich)
Sent: Tuesday, February 03, = 2015 12:56 PM
To: netconf@ietf.org
Subject: [Netconf] Call for = Adoption of two new WG Items splitted from RESTCONF

 

= Dear NETCONF WG,

=  

= providing Restconf Collection and YANG library as separate drafts has been proposed as part of the Restconf issue solving (issues #3 and #13). T= he issues were in VERIFY state some time without objection. As such we assu= me already some agreement for the separation.

=  =

= Restconf Collection and YANG library have been now provided as two sepa= rate drafts:

= https://tools.ietf.org/html/draft-ietf-netconf-restconf-collecti= on-00

= https://tools.ietf.org/html/draft-ietf-netconf-yang-library-00=

=  

= After checking with our AD Benoit, this is the final WG call for the adoption of the two drafts above as WG item documents, with a shorted dead= line for 4 business days.

= If there is no strong objection by February 9, 2015 EOB PT, the co-chai= rs will work with our AD to update the charter deliverables (as the current c= harter covers Restconf and there is no additional feature in these drafts, = the charter text will not be changed).

=  

= @All: Please upload documents in the future as draft-ietf-netconf only after checking with the co-chairs and the approval of the charter update.<= o:p>

=  

= Best Regards,

= Mehmet & Mahesh

 <= /o:p>

--_000_E4DE949E6CE3E34993A2FF8AE79131F81962510ADEMUMBX005nsnin_-- From nobody Fri Feb 13 12:51: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 257CF1A1A2C for ; Fri, 13 Feb 2015 12:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwfJllM_NfOO for ; Fri, 13 Feb 2015 12:51:25 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E771A1A1C for ; Fri, 13 Feb 2015 12:51:24 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BDC7EAD6; Fri, 13 Feb 2015 21:51:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id YUm-ZYgvaa0v; Fri, 13 Feb 2015 21:50:55 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 13 Feb 2015 21:51:23 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1D3F20038; Fri, 13 Feb 2015 21:51:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IXg1qw6diDtg; Fri, 13 Feb 2015 21:51:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F3D820036; Fri, 13 Feb 2015 21:51:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2C6DE3219E7C; Fri, 13 Feb 2015 21:51:21 +0100 (CET) Date: Fri, 13 Feb 2015 21:51:21 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20150213205121.GA53964@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: <20150108111913.GC15995@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] NACM update for YANG 1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 20:51:27 -0000 Mehmet, may I assume that a NACM update can made? Please confirm so that we can move forward with Y58 (and perhaps Y36). /js On Thu, Jan 08, 2015 at 03:20:28PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Juergen, > > thanks for sharing the issue description and the background. > I personally believe we should extend RFC 6536 to support the usage of actions. > > @All: Please comment by January 22, 2015, whether you have any objections to addressing the issue with a rfc6536bis document. > > Regards, > Mehmet > > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 08, 2015 12:19 PM > To: netconf@ietf.org > Cc: netconf-chairs@tools.ietf.org > Subject: NACM update for YANG 1.1 > > Hi, > > the YANG 1.1 work going on in NETMOD has two issues that interact with > the NETCONF access control model (NACM) defined in RFC 6536. YANG 1.1 > issue Y58 provides a mechanism to associate an action with a data > node. (Similarily, Y36 provides a mechanism to associate a > notification with a data node.) > > To fully support Y58 (and perhaps Y36), a minor modification of NACM > would be needed so that access control rights can be associated with > actions. The change is expected to be minor and the editors of RFC > 6536 indicated to be willing to do the work. > > The question now is if NETCONF is willing to do this update if say Y58 > makes it into YANG 1.1. (While there seems to be good support for Y58, > some people raised a concern that we should not have an incomplete > solution where standard access control cannot be configured for > actions.) > > The YANG 1.1 issues list can be found here: > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > > /js > > -- > 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 Fri Feb 13 13:17:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BBD1A1A57 for ; Fri, 13 Feb 2015 13:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmBjaSxkMJL0 for ; Fri, 13 Feb 2015 13:17:03 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB92D1A1A8F for ; Fri, 13 Feb 2015 13:17:00 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t1DLGvoD013777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Feb 2015 21:16:57 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t1DLGvWA006717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Feb 2015 22:16:57 +0100 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 13 Feb 2015 22:16:57 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 22:16:56 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Juergen Schoenwaelder Thread-Topic: NACM update for YANG 1.1 Thread-Index: AQHQR87X8yLkTeVlJU6F2i9/pCzblpzvE5kw Date: Fri, 13 Feb 2015 21:16:56 +0000 Message-ID: References: <20150108111913.GC15995@elstar.local> <20150213205121.GA53964@elstar.local> In-Reply-To: <20150213205121.GA53964@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2845 X-purgate-ID: 151667::1423862218-000067C4-E3AD5C89/0/0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] NACM update for YANG 1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 21:17:06 -0000 Juergen, there were no objections against NACM by the call deadline.=20 Also offline discussion with different draft authors showed that there is a= need. So we may assume there is interest to address NACM as described in your ori= ginal=20 mail below. Cheers,=20 Mehmet=20 -----Original Message----- From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Friday, February 13, 2015 9:51 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: netconf@ietf.org Subject: Re: NACM update for YANG 1.1 Mehmet, may I assume that a NACM update can made? Please confirm so that we can move forward with Y58 (and perhaps Y36). /js On Thu, Jan 08, 2015 at 03:20:28PM +0000, Ersue, Mehmet (NSN - DE/Munich) w= rote: > Hi Juergen, >=20 > thanks for sharing the issue description and the background. > I personally believe we should extend RFC 6536 to support the usage of ac= tions. >=20 > @All: Please comment by January 22, 2015, whether you have any objections= to addressing the issue with a rfc6536bis document. >=20 > Regards, > Mehmet=20 >=20 > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university= .de]=20 > Sent: Thursday, January 08, 2015 12:19 PM > To: netconf@ietf.org > Cc: netconf-chairs@tools.ietf.org > Subject: NACM update for YANG 1.1 >=20 > Hi, >=20 > the YANG 1.1 work going on in NETMOD has two issues that interact with > the NETCONF access control model (NACM) defined in RFC 6536. YANG 1.1 > issue Y58 provides a mechanism to associate an action with a data > node. (Similarily, Y36 provides a mechanism to associate a > notification with a data node.) >=20 > To fully support Y58 (and perhaps Y36), a minor modification of NACM > would be needed so that access control rights can be associated with > actions. The change is expected to be minor and the editors of RFC > 6536 indicated to be willing to do the work. >=20 > The question now is if NETCONF is willing to do this update if say Y58 > makes it into YANG 1.1. (While there seems to be good support for Y58, > some people raised a concern that we should not have an incomplete > solution where standard access control cannot be configured for > actions.) >=20 > The YANG 1.1 issues list can be found here: >=20 > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >=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 --=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 Mon Feb 16 09:09:52 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D971A7008 for ; Mon, 16 Feb 2015 09:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 bvBRtq08MFdA for ; Mon, 16 Feb 2015 09:09:43 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 3C3521A1BAF for ; Mon, 16 Feb 2015 09:09:13 -0800 (PST) Received: by lams18 with SMTP id s18so30869229lam.13 for ; Mon, 16 Feb 2015 09:09:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=IpZFHPfm3bTJ3dwfdDP/uFEnOI6cog8+Tpmey2hNhzU=; b=cK40Zu427aiMmoSasVed1Rd/anMle7SPW5FgAA5Mjwog9lfH5U9inzOPRHxL3j26su PxFqILkuhQJ/169PfRvgH3enwMRX5MTbxDjWOZBZAn2t59M/jTaXjEBgZy+U1ef3v4cT OyejVLOBmR1xP2onkkaT8Jqi4ENNG9NHQPacH8FBTrAB1+VdtyWnrVx/d3T/XbTiTB5d TcBVsleZIykQKkNcQ59a5diQ8x/QG4GlnP116cUModLZC2U6PEXy3Ty/NSmQeoXYjmLv 1J4PlFs6lkqIGn+zyYQDGtcQ3RuxbDkPRXmP0VufVyGXewJiYLjBV5vVYvU+Ysz43W+l A3Tw== X-Gm-Message-State: ALoCoQkl04giL9nU1JwSXlIbaIgH5BIZjXLtBMG1p3HOcDOttDYFVBJ3GFfTHt+1PmyQIYL8Roul MIME-Version: 1.0 X-Received: by 10.152.207.37 with SMTP id lt5mr24166124lac.38.1424106551660; Mon, 16 Feb 2015 09:09:11 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 16 Feb 2015 09:09:11 -0800 (PST) Date: Mon, 16 Feb 2015 09:09:11 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] 3 new related RESTCONF/anyxml Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 17:09:46 -0000 Hi, RESTCONF #17: terminal nodes as resources I just noticed that the term 'data resource' in sec. 1.3.4 does not include leaf-list as a node that can be a data resource. The draft is mostly silent about the processing of terminal nodes as data resources (except patching a leaf). Details and examples for leaf-list and anyxml should be added. Proposed solution: --> leaf-list as data resource rules TBD --> anyxml edited as a whole. Nested data nodes in anyxml mare still part of the anyxml resource, not a new sub-resource RESTCONF #18: depth parameter and anyxml The depth parameter in 4.8.4 says each new child level increments the depth level. The terminology mixes 'data node', 'resource', and 'sub-resource'. Proposed solution: ---> for counting nest levels, sub-resources are counted, not data nodes. anyxml nodes cannot have sub-resources RESTCONF #19: fields parameter and anyxml The fields parameter in 4.8.5 does not say if nested data nodes within an anyxml object can be selected or not. Proposed solution: ---> for selecting nested data nodes, anyxml is treated as a terminal node so no sub-nodes within an instance can be selected with the fields parameter. Andy From nobody Mon Feb 16 21:53: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 B40001A8715 for ; Mon, 16 Feb 2015 21:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrCrDZ2waryg for ; Mon, 16 Feb 2015 21:53:51 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1FE1A19F2 for ; Mon, 16 Feb 2015 21:53:51 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so27844410igq.0 for ; Mon, 16 Feb 2015 21:53:50 -0800 (PST) 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 :cc:content-type; bh=XDI1OovNeLhtA/dTOtZLanEOoTjwnV8JexMavVNyDcQ=; b=ELj4n5b9sxSrJv1+DERCDGjEqwV6JZUu0IuvcxrY99HXRVLcFXtF6trOgRx6IUldF8 5lW4WYCu6R3yzx736wQWbM8MqLymHhSPGEIDUXfa/ODj4vsWI2lgb57eFGjEnXfU5tNu LR3Dq9NT6RW+grDCAtfU86HvuPdtPNQ0/F4SS66JIjB8TGCeTlRdp12N1iThTaPleEEd tTKZSVNSjLFXaw+pRgayQ7ku/1bcZfbO+oZNIQpC5fyL7PnygDsX6qd8M8peU4qZvl48 0W/4TwQEyWu3NVv7//PITImw14rLZ3uiQIA3TTt5d4oA/zx8aBhaY/r35webHSzJTp+3 baOA== MIME-Version: 1.0 X-Received: by 10.50.79.229 with SMTP id m5mr25782767igx.23.1424152430772; Mon, 16 Feb 2015 21:53:50 -0800 (PST) Received: by 10.36.0.15 with HTTP; Mon, 16 Feb 2015 21:53:50 -0800 (PST) In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671E3262@szxeml512-mbs.china.huawei.com> References: <201502051831.t15IVw5U056876@idle.juniper.net> <991B70D8B4112A4699D5C00DDBBF878A671E3249@szxeml512-mbs.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A671E3262@szxeml512-mbs.china.huawei.com> Date: Tue, 17 Feb 2015 11:23:50 +0530 Message-ID: From: Ambika Tripathy To: Rohit R Ranade Content-Type: multipart/alternative; boundary=089e0122a3fabe0564050f42532d Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 05:53:54 -0000 --089e0122a3fabe0564050f42532d Content-Type: text/plain; charset=UTF-8 Hi Rohit, Few thoughts - The datastore push requirements are present in datastore-push draft you stated above and section 3 gives more clear idea. - Along with this, few more requirements i think for NetConf notification can be handled. - multiple create-subscription request in same NetConf ssh session using different channels. Basically multiplexing the same NetConf ssh session with multiple ssh channel. - there should be a way to differentiate between notification subscription and data subscription. - each subscription channel can be treated independently and any one subscription termination shouldn't affect session. br, Ambika Prasad Tripathy On Fri, Feb 13, 2015 at 12:23 PM, Rohit R Ranade wrote: > Hi, > > > > As per your mail about Datastore-push, I referred to the > https://tools.ietf.org/html/draft-netmod-clemm-datastore-push-00 draft of > datastore-push. > > Kindly provide the requirements of data-store-push that needs to be added( > that you currently have in minded) to the extension. I have a scenario, > where maybe datastore-push also might be necessary for my client. > > Maybe based on your thoughts maybe I can also add to those requirements. > > > > With Regards, > > Rohit > > > > *From:* Ambika Tripathy [mailto:ambika.tripathy@gmail.com] > *Sent:* 13 February, 2015 11:37 > *To:* Rohit R Ranade > *Cc:* Alexander Clemm (alex); Phil Shafer; Kent Watsen; netconf@ietf.org > > *Subject:* Re: [Netconf] Notification updation RFC 5277 > > > > Hi, The existing NetConf session with notification definition as per > rfc5277 is very limited to just once subscription for all event in the > system. For different filters in notification, there is a need to create > different session and with unique subscription request. This is not a > efficient solution. > > The mechanism should allow multiple unique create-subscription request in > a session and send the event data based on subscription request and the > subscription should be uniquely identified by one subscription-id for easy > management like RPC, RPC-reply. > > > > The current way of handling notification is very limited to PUB-SUB > mechanism also and not efficient solution. If there will be one extension > to notification mechanism to handle PUB-SUB data, by addressing all > requirements of datastore-push will help a lot. > > > > br, > > Ambika Prasad Tripathy > > > > On Fri, Feb 13, 2015 at 8:31 AM, Rohit R Ranade > wrote: > > Hi, Is there any update on this ? Preferably a solution which does not > involve tearing down and bringing up a session will be welcome. > The notifications lost during the time period for which the session is > down. A separate mechanism to be used to get them back and the subsequent > handling will make it very complicated. > Kindly help. > > With Regards, > Rohit > > -----Original Message----- > From: Alexander Clemm (alex) [mailto:alex@cisco.com] > Sent: 06 February, 2015 00:41 > To: Phil Shafer; Kent Watsen > Cc: Rohit R Ranade; netconf@ietf.org > > Subject: RE: [Netconf] Notification updation RFC 5277 > > Stability is all good, assuming it can be reasonably adapted to > requirements. The other side of the stability coin would be inflexibility. > The need to adjust subscriptions appears fairly reasonable; we are also > seeing this in conjunction with datastore-push. So, I for one would think > it reasonable to look into extensions to accommodate such. > --- Alex > > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer > Sent: Thursday, February 05, 2015 10:32 AM > To: Kent Watsen > Cc: Rohit R Ranade; netconf@ietf.org > Subject: Re: [Netconf] Notification updation RFC 5277 > > Kent Watsen writes: > >>Not with RFC 5277 - there is no delete-subscription in RFC 5277. > >Poor man's delete: drop the underlying NETCONF session. > > ;^) > > >The assumption is > >that there is a dedicated NETCONF session for each subscription (no > >interleaving). Using SSH channels, this can be a fairly cheap > >operation, reusing the same underlying SSH connection. > > If we could have made that assumption, the notification mechanism would > have been oh-so easy. Instead we designed for interleaving notifications > and s. I thing it's too late to start requiring that assumption > (unless we want to redesign notifications (which would be a great idea > (except for my previous comments re: > stability and "done"-ness))). > > Thanks, > Phil > > _______________________________________________ > 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 > > > > > > -- > > Ambika Prasad Tripathy > > Cell @+91 9437547730/8553070866 > > Alt email: ambika_tripathy@yahoo.com > > ambika.tripathy@gmail.com > > skype:ambika_nethawk > -- Ambika Prasad Tripathy Cell @+91 9437547730/8553070866 Alt email: ambika_tripathy@yahoo.com ambika.tripathy@gmail.com skype:ambika_nethawk --089e0122a3fabe0564050f42532d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rohit,

Few thoughts
- The = datastore push requirements are present in datastore-push draft you stated = above and section 3 gives more clear idea.
- Along with this, few= more requirements i think for NetConf notification can be =C2=A0handled.
=C2=A0 =C2=A0- multiple create-subscription request in same NetCon= f ssh session using different channels. Basically multiplexing the same Net= Conf ssh session with multiple ssh channel.
=C2=A0 =C2=A0- there = should be a way to differentiate between notification subscription and data= subscription.
=C2=A0 =C2=A0- each subscription channel can be tr= eated independently and any one subscription termination shouldn't affe= ct session.
=C2=A0 =C2=A0
br,
Ambika Prasad T= ripathy


On Fri, Feb 13, 2015 at 12:23 PM, Rohit R Ranade <r= ohitrranade@huawei.com> wrote:

Hi,<= /p>

=C2=A0

As per your mail about Da= tastore-push, I referred to the https://tools.ietf.org/html/draft-netmod-clemm-datastor= e-push-00 draft of datastore-push.

Kindly provide the requir= ements of data-store-push that needs to be added( that you currently have i= n minded) to the extension. I have a scenario, where maybe datastore-push also might be necessary for my client.

Maybe based on your thoug= hts maybe I can also add to those requirements.

=C2=A0

With Regards,

Rohit

=C2=A0

From: Ambika T= ripathy [mailto:ambika.tripathy@gmail.com]
Sent: 13 February, 2015 11:37
To: Rohit R Ranade
Cc: Alexander Clemm (alex); Phil Shafer; Kent Watsen; netconf@ietf.org


Subject: Re: [Netconf] Notification updation RFC 5277<= /div>

=C2=A0

Hi, The existing NetConf session with notification d= efinition as per rfc5277 is very limited to just once subscription for all = event in the system. For different filters in notification, there is a need= to create different session and with unique subscription request. This is not a efficient solution.=C2=A0

The mechanism should allow multiple unique create-su= bscription request in a session and send the event data based on subscripti= on request and the subscription should =C2=A0be uniquely identified by one = subscription-id for easy management like RPC, RPC-reply.=C2=A0

=C2=A0

The current way of handling notification is very lim= ited to PUB-SUB mechanism also and not efficient solution. If there will be= one extension to notification mechanism to handle PUB-SUB data, by address= ing all requirements of datastore-push will help a lot.

=C2=A0

br,

Ambika Prasad Tripathy

=C2=A0

On Fri, Feb 13, 2015 at 8:31 AM, Rohit R Ranade <= rohitrranade@h= uawei.com> wrote:

Hi, Is there any update on this ? Preferably a solut= ion which does not involve tearing down and bringing up a session will be w= elcome.
The notifications lost during the time period for which the session is down= . A separate mechanism to be used to get them back and the subsequent handl= ing will make it very complicated.
Kindly help.

With Regards,
Rohit

-----Original Message-----
From: Alexander Clemm (alex) [mailto:alex@cisco.com]
Sent: 06 February, 2015 00:41
To: Phil Shafer; Kent Watsen
Cc: Rohit R Ranade; netconf@ietf.org

Subject: RE: [Netconf] Notification updation RFC 527= 7

Stability is all good, assuming it can be reasonably adapted to requirement= s.=C2=A0 The other side of the stability coin would be inflexibility.
The need to adjust subscriptions appears fairly reasonable; we are also see= ing this in conjunction with datastore-push.=C2=A0 So, I for one would thin= k it reasonable to look into extensions to accommodate such.
--- Alex


-----Original Message-----
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer
Sent: Thursday, February 05, 2015 10:32 AM
To: Kent Watsen
Cc: Rohit R Ranade; n= etconf@ietf.org
Subject: Re: [Netconf] Notification updation RFC 5277

Kent Watsen writes:
>>Not with RFC 5277 - there is no delete-subscription in RFC 5277. >Poor man's delete: drop the underlying NETCONF session.

;^)

>The assumption is
>that there is a dedicated NETCONF session for each subscription (no
>interleaving).=C2=A0 Using SSH channels, this can be a fairly cheap
>operation, reusing the same underlying SSH connection.

If we could have made that assumption, the notification mechanism would hav= e been oh-so easy.=C2=A0 Instead we designed for interleaving notifications= and <rpc-reply>s.=C2=A0 I thing it's too late to start requiring= that assumption (unless we want to redesign notifications (which would be a great idea (except for my previous comments re:
stability and "done"-ness))).

Thanks,
=C2=A0Phil

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

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



=C2=A0

--

Ambika Prasad Tripathy

skype:ambika_nethawk




--
Ambika Prasad Tripathy
Cell @+91 9437547730/8553070866
skype:ambika_nethawk
--089e0122a3fabe0564050f42532d-- From nobody Mon Feb 16 22:20:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0DA1A8720 for ; Mon, 16 Feb 2015 22:20:40 -0800 (PST) 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 PvgZPkCWHF3m for ; Mon, 16 Feb 2015 22:20:37 -0800 (PST) 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 3F32E1A871F for ; Mon, 16 Feb 2015 22:20:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPJ16553; Tue, 17 Feb 2015 06:20:34 +0000 (GMT) Received: from SZXEML427-HUB.china.huawei.com (10.82.67.182) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Feb 2015 06:20:32 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.141]) by szxeml427-hub.china.huawei.com ([10.82.67.182]) with mapi id 14.03.0158.001; Tue, 17 Feb 2015 14:20:22 +0800 From: Rohit R Ranade To: Ambika Tripathy Thread-Topic: [Netconf] Notification updation RFC 5277 Thread-Index: AdAdmGPAceznqgnXSje9O6PD47W4GwKspEggBix6hTAAAhGVgAAEnTcAAABOrgAAAoyFgAAC/EgAAAFgtoABgRO+gP//ruCA//9t0yCABtfRAP//c4wQ Date: Tue, 17 Feb 2015 06:20:22 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A671E3384@szxeml512-mbs.china.huawei.com> References: <201502051831.t15IVw5U056876@idle.juniper.net> <991B70D8B4112A4699D5C00DDBBF878A671E3249@szxeml512-mbs.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A671E3262@szxeml512-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.144.92] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A671E3384szxeml512mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 06:20:41 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A671E3384szxeml512mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCi0gbXVsdGlwbGUgY3JlYXRlLXN1YnNjcmlwdGlvbiByZXF1ZXN0IGluIHNhbWUgTmV0 Q29uZiBzc2ggc2Vzc2lvbiB1c2luZyBkaWZmZXJlbnQgY2hhbm5lbHMuIEJhc2ljYWxseSBtdWx0 aXBsZXhpbmcgdGhlIHNhbWUgTmV0Q29uZiBzc2ggc2Vzc2lvbiB3aXRoIG11bHRpcGxlIHNzaCBj aGFubmVsLg0KLS0+IFRoaXMgcG9pbnQgSSBkaWQgbm90IHVuZGVyc3RhbmQuIERvIHlvdSBtZWFu LCB0aGF0IHRoZXJlIHdpbGwgYmUgbXVsdGlwbGUgU1NIIHNlc3Npb25zIHdpdGggc2luZ2xlIE5F VENPTkZTIHNlc3Npb24gPw0KSSBndWVzcyB5b3VyIGludGVudGlvbiBpcyB0aGF0IHlvdSB3YW50 IHRvIHN1YnNldCBlYWNoIG5vdGlmaWNhdGlvbiwgYW5kIHdhbnQgdG8gZ2V0IHRob3NlIHN1YnNl dHMgaW4gZGlmZmVyZW50IFNTSCBjaGFubmVsIGZvciBsb2FkIGJhbGFuY2luZyA/DQoNCldpdGgg UmVnYXJkcywNClJvaGl0DQoNCkZyb206IEFtYmlrYSBUcmlwYXRoeSBbbWFpbHRvOmFtYmlrYS50 cmlwYXRoeUBnbWFpbC5jb21dDQpTZW50OiAxNyBGZWJydWFyeSwgMjAxNSAxMToyNA0KVG86IFJv aGl0IFIgUmFuYWRlDQpDYzogQWxleGFuZGVyIENsZW1tIChhbGV4KTsgUGhpbCBTaGFmZXI7IEtl bnQgV2F0c2VuOyBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIE5vdGlm aWNhdGlvbiB1cGRhdGlvbiBSRkMgNTI3Nw0KDQpIaSBSb2hpdCwNCg0KRmV3IHRob3VnaHRzDQot IFRoZSBkYXRhc3RvcmUgcHVzaCByZXF1aXJlbWVudHMgYXJlIHByZXNlbnQgaW4gZGF0YXN0b3Jl LXB1c2ggZHJhZnQgeW91IHN0YXRlZCBhYm92ZSBhbmQgc2VjdGlvbiAzIGdpdmVzIG1vcmUgY2xl YXIgaWRlYS4NCi0gQWxvbmcgd2l0aCB0aGlzLCBmZXcgbW9yZSByZXF1aXJlbWVudHMgaSB0aGlu ayBmb3IgTmV0Q29uZiBub3RpZmljYXRpb24gY2FuIGJlICBoYW5kbGVkLg0KICAgLSBtdWx0aXBs ZSBjcmVhdGUtc3Vic2NyaXB0aW9uIHJlcXVlc3QgaW4gc2FtZSBOZXRDb25mIHNzaCBzZXNzaW9u IHVzaW5nIGRpZmZlcmVudCBjaGFubmVscy4gQmFzaWNhbGx5IG11bHRpcGxleGluZyB0aGUgc2Ft ZSBOZXRDb25mIHNzaCBzZXNzaW9uIHdpdGggbXVsdGlwbGUgc3NoIGNoYW5uZWwuDQogICAtIHRo ZXJlIHNob3VsZCBiZSBhIHdheSB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gbm90aWZpY2F0aW9u IHN1YnNjcmlwdGlvbiBhbmQgZGF0YSBzdWJzY3JpcHRpb24uDQogICAtIGVhY2ggc3Vic2NyaXB0 aW9uIGNoYW5uZWwgY2FuIGJlIHRyZWF0ZWQgaW5kZXBlbmRlbnRseSBhbmQgYW55IG9uZSBzdWJz Y3JpcHRpb24gdGVybWluYXRpb24gc2hvdWxkbid0IGFmZmVjdCBzZXNzaW9uLg0KDQpiciwNCkFt YmlrYSBQcmFzYWQgVHJpcGF0aHkNCg0KDQpPbiBGcmksIEZlYiAxMywgMjAxNSBhdCAxMjoyMyBQ TSwgUm9oaXQgUiBSYW5hZGUgPHJvaGl0cnJhbmFkZUBodWF3ZWkuY29tPG1haWx0bzpyb2hpdHJy YW5hZGVAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGksDQoNCkFzIHBlciB5b3VyIG1haWwgYWJvdXQg RGF0YXN0b3JlLXB1c2gsIEkgcmVmZXJyZWQgdG8gdGhlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1uZXRtb2QtY2xlbW0tZGF0YXN0b3JlLXB1c2gtMDAgZHJhZnQgb2YgZGF0YXN0 b3JlLXB1c2guDQpLaW5kbHkgcHJvdmlkZSB0aGUgcmVxdWlyZW1lbnRzIG9mIGRhdGEtc3RvcmUt cHVzaCB0aGF0IG5lZWRzIHRvIGJlIGFkZGVkKCB0aGF0IHlvdSBjdXJyZW50bHkgaGF2ZSBpbiBt aW5kZWQpIHRvIHRoZSBleHRlbnNpb24uIEkgaGF2ZSBhIHNjZW5hcmlvLCB3aGVyZSBtYXliZSBk YXRhc3RvcmUtcHVzaCBhbHNvIG1pZ2h0IGJlIG5lY2Vzc2FyeSBmb3IgbXkgY2xpZW50Lg0KTWF5 YmUgYmFzZWQgb24geW91ciB0aG91Z2h0cyBtYXliZSBJIGNhbiBhbHNvIGFkZCB0byB0aG9zZSBy ZXF1aXJlbWVudHMuDQoNCldpdGggUmVnYXJkcywNClJvaGl0DQoNCkZyb206IEFtYmlrYSBUcmlw YXRoeSBbbWFpbHRvOmFtYmlrYS50cmlwYXRoeUBnbWFpbC5jb208bWFpbHRvOmFtYmlrYS50cmlw YXRoeUBnbWFpbC5jb20+XQ0KU2VudDogMTMgRmVicnVhcnksIDIwMTUgMTE6MzcNClRvOiBSb2hp dCBSIFJhbmFkZQ0KQ2M6IEFsZXhhbmRlciBDbGVtbSAoYWxleCk7IFBoaWwgU2hhZmVyOyBLZW50 IFdhdHNlbjsgbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCg0KU3Vi amVjdDogUmU6IFtOZXRjb25mXSBOb3RpZmljYXRpb24gdXBkYXRpb24gUkZDIDUyNzcNCg0KSGks IFRoZSBleGlzdGluZyBOZXRDb25mIHNlc3Npb24gd2l0aCBub3RpZmljYXRpb24gZGVmaW5pdGlv biBhcyBwZXIgcmZjNTI3NyBpcyB2ZXJ5IGxpbWl0ZWQgdG8ganVzdCBvbmNlIHN1YnNjcmlwdGlv biBmb3IgYWxsIGV2ZW50IGluIHRoZSBzeXN0ZW0uIEZvciBkaWZmZXJlbnQgZmlsdGVycyBpbiBu b3RpZmljYXRpb24sIHRoZXJlIGlzIGEgbmVlZCB0byBjcmVhdGUgZGlmZmVyZW50IHNlc3Npb24g YW5kIHdpdGggdW5pcXVlIHN1YnNjcmlwdGlvbiByZXF1ZXN0LiBUaGlzIGlzIG5vdCBhIGVmZmlj aWVudCBzb2x1dGlvbi4NClRoZSBtZWNoYW5pc20gc2hvdWxkIGFsbG93IG11bHRpcGxlIHVuaXF1 ZSBjcmVhdGUtc3Vic2NyaXB0aW9uIHJlcXVlc3QgaW4gYSBzZXNzaW9uIGFuZCBzZW5kIHRoZSBl dmVudCBkYXRhIGJhc2VkIG9uIHN1YnNjcmlwdGlvbiByZXF1ZXN0IGFuZCB0aGUgc3Vic2NyaXB0 aW9uIHNob3VsZCAgYmUgdW5pcXVlbHkgaWRlbnRpZmllZCBieSBvbmUgc3Vic2NyaXB0aW9uLWlk IGZvciBlYXN5IG1hbmFnZW1lbnQgbGlrZSBSUEMsIFJQQy1yZXBseS4NCg0KVGhlIGN1cnJlbnQg d2F5IG9mIGhhbmRsaW5nIG5vdGlmaWNhdGlvbiBpcyB2ZXJ5IGxpbWl0ZWQgdG8gUFVCLVNVQiBt ZWNoYW5pc20gYWxzbyBhbmQgbm90IGVmZmljaWVudCBzb2x1dGlvbi4gSWYgdGhlcmUgd2lsbCBi ZSBvbmUgZXh0ZW5zaW9uIHRvIG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gdG8gaGFuZGxlIFBVQi1T VUIgZGF0YSwgYnkgYWRkcmVzc2luZyBhbGwgcmVxdWlyZW1lbnRzIG9mIGRhdGFzdG9yZS1wdXNo IHdpbGwgaGVscCBhIGxvdC4NCg0KYnIsDQpBbWJpa2EgUHJhc2FkIFRyaXBhdGh5DQoNCk9uIEZy aSwgRmViIDEzLCAyMDE1IGF0IDg6MzEgQU0sIFJvaGl0IFIgUmFuYWRlIDxyb2hpdHJyYW5hZGVA aHVhd2VpLmNvbTxtYWlsdG86cm9oaXRycmFuYWRlQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpLCBJ cyB0aGVyZSBhbnkgdXBkYXRlIG9uIHRoaXMgPyBQcmVmZXJhYmx5IGEgc29sdXRpb24gd2hpY2gg ZG9lcyBub3QgaW52b2x2ZSB0ZWFyaW5nIGRvd24gYW5kIGJyaW5naW5nIHVwIGEgc2Vzc2lvbiB3 aWxsIGJlIHdlbGNvbWUuDQpUaGUgbm90aWZpY2F0aW9ucyBsb3N0IGR1cmluZyB0aGUgdGltZSBw ZXJpb2QgZm9yIHdoaWNoIHRoZSBzZXNzaW9uIGlzIGRvd24uIEEgc2VwYXJhdGUgbWVjaGFuaXNt IHRvIGJlIHVzZWQgdG8gZ2V0IHRoZW0gYmFjayBhbmQgdGhlIHN1YnNlcXVlbnQgaGFuZGxpbmcg d2lsbCBtYWtlIGl0IHZlcnkgY29tcGxpY2F0ZWQuDQpLaW5kbHkgaGVscC4NCg0KV2l0aCBSZWdh cmRzLA0KUm9oaXQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFsZXhhbmRl ciBDbGVtbSAoYWxleCkgW21haWx0bzphbGV4QGNpc2NvLmNvbTxtYWlsdG86YWxleEBjaXNjby5j b20+XQ0KU2VudDogMDYgRmVicnVhcnksIDIwMTUgMDA6NDENClRvOiBQaGlsIFNoYWZlcjsgS2Vu dCBXYXRzZW4NCkNjOiBSb2hpdCBSIFJhbmFkZTsgbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0 Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbTmV0Y29uZl0gTm90aWZpY2F0aW9uIHVwZGF0 aW9uIFJGQyA1Mjc3DQoNClN0YWJpbGl0eSBpcyBhbGwgZ29vZCwgYXNzdW1pbmcgaXQgY2FuIGJl IHJlYXNvbmFibHkgYWRhcHRlZCB0byByZXF1aXJlbWVudHMuICBUaGUgb3RoZXIgc2lkZSBvZiB0 aGUgc3RhYmlsaXR5IGNvaW4gd291bGQgYmUgaW5mbGV4aWJpbGl0eS4NClRoZSBuZWVkIHRvIGFk anVzdCBzdWJzY3JpcHRpb25zIGFwcGVhcnMgZmFpcmx5IHJlYXNvbmFibGU7IHdlIGFyZSBhbHNv IHNlZWluZyB0aGlzIGluIGNvbmp1bmN0aW9uIHdpdGggZGF0YXN0b3JlLXB1c2guICBTbywgSSBm b3Igb25lIHdvdWxkIHRoaW5rIGl0IHJlYXNvbmFibGUgdG8gbG9vayBpbnRvIGV4dGVuc2lvbnMg dG8gYWNjb21tb2RhdGUgc3VjaC4NCi0tLSBBbGV4DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBQaGlsIFNoYWZlcg0K U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE1IDEwOjMyIEFNDQpUbzogS2VudCBXYXRz ZW4NCkNjOiBSb2hpdCBSIFJhbmFkZTsgbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gTm90aWZpY2F0aW9uIHVwZGF0aW9uIFJG QyA1Mjc3DQoNCktlbnQgV2F0c2VuIHdyaXRlczoNCj4+Tm90IHdpdGggUkZDIDUyNzcgLSB0aGVy ZSBpcyBubyBkZWxldGUtc3Vic2NyaXB0aW9uIGluIFJGQyA1Mjc3Lg0KPlBvb3IgbWFuJ3MgZGVs ZXRlOiBkcm9wIHRoZSB1bmRlcmx5aW5nIE5FVENPTkYgc2Vzc2lvbi4NCg0KO14pDQoNCj5UaGUg YXNzdW1wdGlvbiBpcw0KPnRoYXQgdGhlcmUgaXMgYSBkZWRpY2F0ZWQgTkVUQ09ORiBzZXNzaW9u IGZvciBlYWNoIHN1YnNjcmlwdGlvbiAobm8NCj5pbnRlcmxlYXZpbmcpLiAgVXNpbmcgU1NIIGNo YW5uZWxzLCB0aGlzIGNhbiBiZSBhIGZhaXJseSBjaGVhcA0KPm9wZXJhdGlvbiwgcmV1c2luZyB0 aGUgc2FtZSB1bmRlcmx5aW5nIFNTSCBjb25uZWN0aW9uLg0KDQpJZiB3ZSBjb3VsZCBoYXZlIG1h ZGUgdGhhdCBhc3N1bXB0aW9uLCB0aGUgbm90aWZpY2F0aW9uIG1lY2hhbmlzbSB3b3VsZCBoYXZl IGJlZW4gb2gtc28gZWFzeS4gIEluc3RlYWQgd2UgZGVzaWduZWQgZm9yIGludGVybGVhdmluZyBu b3RpZmljYXRpb25zIGFuZCA8cnBjLXJlcGx5PnMuICBJIHRoaW5nIGl0J3MgdG9vIGxhdGUgdG8g c3RhcnQgcmVxdWlyaW5nIHRoYXQgYXNzdW1wdGlvbiAodW5sZXNzIHdlIHdhbnQgdG8gcmVkZXNp Z24gbm90aWZpY2F0aW9ucyAod2hpY2ggd291bGQgYmUgYSBncmVhdCBpZGVhIChleGNlcHQgZm9y IG15IHByZXZpb3VzIGNvbW1lbnRzIHJlOg0Kc3RhYmlsaXR5IGFuZCAiZG9uZSItbmVzcykpKS4N Cg0KVGhhbmtzLA0KIFBoaWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0 bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29u ZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u Zg0KDQoNCg0KLS0NCkFtYmlrYSBQcmFzYWQgVHJpcGF0aHkNCkNlbGwgQCs5MSA5NDM3NTQ3NzMw PHRlbDolMkI5MSUyMDk0Mzc1NDc3MzA+Lzg1NTMwNzA4NjY8dGVsOjg1NTMwNzA4NjY+DQpBbHQg ZW1haWw6IGFtYmlrYV90cmlwYXRoeUB5YWhvby5jb208bWFpbHRvOmFtYmlrYV90cmlwYXRoeUB5 YWhvby5jb20+DQphbWJpa2EudHJpcGF0aHlAZ21haWwuY29tPG1haWx0bzphbWJpa2EudHJpcGF0 aHlAZ21haWwuY29tPg0Kc2t5cGU6YW1iaWthX25ldGhhd2sNCg0KDQoNCi0tDQpBbWJpa2EgUHJh c2FkIFRyaXBhdGh5DQpDZWxsIEArOTEgOTQzNzU0NzczMC84NTUzMDcwODY2DQpBbHQgZW1haWw6 IGFtYmlrYV90cmlwYXRoeUB5YWhvby5jb208bWFpbHRvOmFtYmlrYV90cmlwYXRoeUB5YWhvby5j b20+DQphbWJpa2EudHJpcGF0aHlAZ21haWwuY29tPG1haWx0bzphbWJpa2EudHJpcGF0aHlAZ21h aWwuY29tPg0Kc2t5cGU6YW1iaWthX25ldGhhd2sNCg== --_000_991B70D8B4112A4699D5C00DDBBF878A671E3384szxeml512mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBtdWx0aXBsZSBj cmVhdGUtc3Vic2NyaXB0aW9uIHJlcXVlc3QgaW4gc2FtZSBOZXRDb25mIHNzaCBzZXNzaW9uIHVz aW5nIGRpZmZlcmVudCBjaGFubmVscy4gQmFzaWNhbGx5IG11bHRpcGxleGluZyB0aGUgc2FtZSBO ZXRDb25mIHNzaCBzZXNzaW9uIHdpdGggbXVsdGlwbGUgc3NoIGNoYW5uZWwuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rp bmdzIj7DoDwvc3Bhbj4gVGhpcyBwb2ludCBJIGRpZCBub3QgdW5kZXJzdGFuZC4gRG8geW91IG1l YW4sIHRoYXQgdGhlcmUgd2lsbCBiZSBtdWx0aXBsZSBTU0ggc2Vzc2lvbnMgd2l0aCBzaW5nbGUg TkVUQ09ORlMgc2Vzc2lvbiA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGd1ZXNzIHlvdXIgaW50ZW50aW9uIGlzIHRoYXQgeW91IHdhbnQgdG8gc3Vic2V0IGVhY2ggbm90 aWZpY2F0aW9uLCBhbmQgd2FudCB0byBnZXQgdGhvc2Ugc3Vic2V0cyBpbiBkaWZmZXJlbnQgU1NI IGNoYW5uZWwgZm9yIGxvYWQgYmFsYW5jaW5nID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0 aCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9oaXQ8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbWJp a2EgVHJpcGF0aHkgW21haWx0bzphbWJpa2EudHJpcGF0aHlAZ21haWwuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IDE3IEZlYnJ1YXJ5LCAyMDE1IDExOjI0PGJyPg0KPGI+VG86PC9iPiBSb2hpdCBS IFJhbmFkZTxicj4NCjxiPkNjOjwvYj4gQWxleGFuZGVyIENsZW1tIChhbGV4KTsgUGhpbCBTaGFm ZXI7IEtlbnQgV2F0c2VuOyBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbTmV0Y29uZl0gTm90aWZpY2F0aW9uIHVwZGF0aW9uIFJGQyA1Mjc3PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBSb2hpdCw8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZldyB0aG91Z2h0czxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBUaGUgZGF0YXN0b3JlIHB1 c2ggcmVxdWlyZW1lbnRzIGFyZSBwcmVzZW50IGluIGRhdGFzdG9yZS1wdXNoIGRyYWZ0IHlvdSBz dGF0ZWQgYWJvdmUgYW5kIHNlY3Rpb24gMyBnaXZlcyBtb3JlIGNsZWFyIGlkZWEuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEFsb25nIHdpdGgg dGhpcywgZmV3IG1vcmUgcmVxdWlyZW1lbnRzIGkgdGhpbmsgZm9yIE5ldENvbmYgbm90aWZpY2F0 aW9uIGNhbiBiZSAmbmJzcDtoYW5kbGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOy0gbXVsdGlwbGUgY3JlYXRlLXN1YnNj cmlwdGlvbiByZXF1ZXN0IGluIHNhbWUgTmV0Q29uZiBzc2ggc2Vzc2lvbiB1c2luZyBkaWZmZXJl bnQgY2hhbm5lbHMuIEJhc2ljYWxseSBtdWx0aXBsZXhpbmcgdGhlIHNhbWUgTmV0Q29uZiBzc2gg c2Vzc2lvbiB3aXRoIG11bHRpcGxlIHNzaCBjaGFubmVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOy0gdGhlcmUgc2hvdWxk IGJlIGEgd2F5IHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBub3RpZmljYXRpb24gc3Vic2NyaXB0 aW9uIGFuZCBkYXRhIHN1YnNjcmlwdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDstIGVhY2ggc3Vic2NyaXB0aW9uIGNo YW5uZWwgY2FuIGJlIHRyZWF0ZWQgaW5kZXBlbmRlbnRseSBhbmQgYW55IG9uZSBzdWJzY3JpcHRp b24gdGVybWluYXRpb24gc2hvdWxkbid0IGFmZmVjdCBzZXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YnIsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbWJpa2EgUHJhc2Fk IFRyaXBhdGh5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gRnJpLCBGZWIgMTMsIDIwMTUgYXQgMTI6MjMgUE0sIFJvaGl0IFIgUmFuYWRl ICZsdDs8YSBocmVmPSJtYWlsdG86cm9oaXRycmFuYWRlQGh1YXdlaS5jb20iIHRhcmdldD0iX2Js YW5rIj5yb2hpdHJyYW5hZGVAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBwZXIgeW91ciBt YWlsIGFib3V0IERhdGFzdG9yZS1wdXNoLCBJIHJlZmVycmVkIHRvIHRoZQ0KPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5ldG1vZC1jbGVtbS1kYXRhc3RvcmUtcHVz aC0wMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LW5ldG1vZC1jbGVtbS1kYXRhc3RvcmUtcHVzaC0wMDwvYT4gZHJhZnQgb2YgZGF0YXN0b3JlLXB1 c2guDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5LaW5kbHkgcHJvdmlkZSB0aGUg cmVxdWlyZW1lbnRzIG9mIGRhdGEtc3RvcmUtcHVzaCB0aGF0IG5lZWRzIHRvIGJlIGFkZGVkKCB0 aGF0IHlvdSBjdXJyZW50bHkgaGF2ZQ0KIGluIG1pbmRlZCkgdG8gdGhlIGV4dGVuc2lvbi4gSSBo YXZlIGEgc2NlbmFyaW8sIHdoZXJlIG1heWJlIGRhdGFzdG9yZS1wdXNoIGFsc28gbWlnaHQgYmUg bmVjZXNzYXJ5IGZvciBteSBjbGllbnQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5NYXliZSBiYXNlZCBvbiB5b3VyIHRob3VnaHRzIG1heWJlIEkgY2FuIGFsc28gYWRkIHRvIHRo b3NlIHJlcXVpcmVtZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaXRoIFJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9oaXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbWJpa2EgVHJpcGF0 aHkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YW1iaWthLnRyaXBhdGh5QGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmFtYmlrYS50cmlwYXRoeUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IDEzIEZlYnJ1YXJ5LCAyMDE1IDExOjM3PGJyPg0KPGI+VG86PC9iPiBSb2hpdCBSIFJh bmFkZTxicj4NCjxiPkNjOjwvYj4gQWxleGFuZGVyIENsZW1tIChhbGV4KTsgUGhpbCBTaGFmZXI7 IEtlbnQgV2F0c2VuOyA8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0KbmV0Y29uZkBpZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W05ldGNvbmZdIE5vdGlmaWNhdGlvbiB1cGRhdGlvbiBSRkMgNTI3NzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SGksIFRoZSBleGlzdGluZyBOZXRDb25mIHNlc3Npb24gd2l0aCBub3RpZmljYXRpb24gZGVmaW5p dGlvbiBhcyBwZXIgcmZjNTI3NyBpcyB2ZXJ5IGxpbWl0ZWQgdG8ganVzdCBvbmNlIHN1YnNjcmlw dGlvbiBmb3IgYWxsIGV2ZW50IGluIHRoZSBzeXN0ZW0uIEZvciBkaWZmZXJlbnQgZmlsdGVycyBp biBub3RpZmljYXRpb24sDQogdGhlcmUgaXMgYSBuZWVkIHRvIGNyZWF0ZSBkaWZmZXJlbnQgc2Vz c2lvbiBhbmQgd2l0aCB1bmlxdWUgc3Vic2NyaXB0aW9uIHJlcXVlc3QuIFRoaXMgaXMgbm90IGEg ZWZmaWNpZW50IHNvbHV0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhlIG1lY2hhbmlzbSBzaG91bGQgYWxsb3cgbXVsdGlwbGUgdW5pcXVl IGNyZWF0ZS1zdWJzY3JpcHRpb24gcmVxdWVzdCBpbiBhIHNlc3Npb24gYW5kIHNlbmQgdGhlIGV2 ZW50IGRhdGEgYmFzZWQgb24gc3Vic2NyaXB0aW9uIHJlcXVlc3QgYW5kIHRoZSBzdWJzY3JpcHRp b24gc2hvdWxkICZuYnNwO2JlIHVuaXF1ZWx5DQogaWRlbnRpZmllZCBieSBvbmUgc3Vic2NyaXB0 aW9uLWlkIGZvciBlYXN5IG1hbmFnZW1lbnQgbGlrZSBSUEMsIFJQQy1yZXBseS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGN1cnJlbnQgd2F5IG9m IGhhbmRsaW5nIG5vdGlmaWNhdGlvbiBpcyB2ZXJ5IGxpbWl0ZWQgdG8gUFVCLVNVQiBtZWNoYW5p c20gYWxzbyBhbmQgbm90IGVmZmljaWVudCBzb2x1dGlvbi4gSWYgdGhlcmUgd2lsbCBiZSBvbmUg ZXh0ZW5zaW9uIHRvIG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gdG8gaGFuZGxlDQogUFVCLVNVQiBk YXRhLCBieSBhZGRyZXNzaW5nIGFsbCByZXF1aXJlbWVudHMgb2YgZGF0YXN0b3JlLXB1c2ggd2ls bCBoZWxwIGEgbG90LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmJyLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbWJpa2EgUHJhc2FkIFRyaXBhdGh5PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBGcmksIEZlYiAxMywgMjAxNSBhdCA4OjMxIEFNLCBSb2hpdCBSIFJhbmFkZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJvaGl0cnJhbmFkZUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9oaXRy cmFuYWRlQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SGksIElzIHRoZXJlIGFueSB1cGRhdGUgb24gdGhpcyA/IFByZWZlcmFi bHkgYSBzb2x1dGlvbiB3aGljaCBkb2VzIG5vdCBpbnZvbHZlIHRlYXJpbmcgZG93biBhbmQgYnJp bmdpbmcgdXAgYSBzZXNzaW9uIHdpbGwgYmUgd2VsY29tZS48YnI+DQpUaGUgbm90aWZpY2F0aW9u cyBsb3N0IGR1cmluZyB0aGUgdGltZSBwZXJpb2QgZm9yIHdoaWNoIHRoZSBzZXNzaW9uIGlzIGRv d24uIEEgc2VwYXJhdGUgbWVjaGFuaXNtIHRvIGJlIHVzZWQgdG8gZ2V0IHRoZW0gYmFjayBhbmQg dGhlIHN1YnNlcXVlbnQgaGFuZGxpbmcgd2lsbCBtYWtlIGl0IHZlcnkgY29tcGxpY2F0ZWQuPGJy Pg0KS2luZGx5IGhlbHAuPGJyPg0KPGJyPg0KV2l0aCBSZWdhcmRzLDxicj4NClJvaGl0PGJyPg0K PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBBbGV4YW5kZXIgQ2xl bW0gKGFsZXgpIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFsZXhAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+YWxleEBjaXNjby5jb208L2E+XTxicj4NClNlbnQ6IDA2IEZlYnJ1YXJ5LCAyMDE1 IDAwOjQxPGJyPg0KVG86IFBoaWwgU2hhZmVyOyBLZW50IFdhdHNlbjxicj4NCkNjOiBSb2hpdCBS IFJhbmFkZTsgPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5uZXRjb25mQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlN1YmplY3Q6IFJFOiBbTmV0Y29uZl0gTm90aWZpY2F0aW9uIHVw ZGF0aW9uIFJGQyA1Mjc3PGJyPg0KPGJyPg0KU3RhYmlsaXR5IGlzIGFsbCBnb29kLCBhc3N1bWlu ZyBpdCBjYW4gYmUgcmVhc29uYWJseSBhZGFwdGVkIHRvIHJlcXVpcmVtZW50cy4mbmJzcDsgVGhl IG90aGVyIHNpZGUgb2YgdGhlIHN0YWJpbGl0eSBjb2luIHdvdWxkIGJlIGluZmxleGliaWxpdHku PGJyPg0KVGhlIG5lZWQgdG8gYWRqdXN0IHN1YnNjcmlwdGlvbnMgYXBwZWFycyBmYWlybHkgcmVh c29uYWJsZTsgd2UgYXJlIGFsc28gc2VlaW5nIHRoaXMgaW4gY29uanVuY3Rpb24gd2l0aCBkYXRh c3RvcmUtcHVzaC4mbmJzcDsgU28sIEkgZm9yIG9uZSB3b3VsZCB0aGluayBpdCByZWFzb25hYmxl IHRvIGxvb2sgaW50byBleHRlbnNpb25zIHRvIGFjY29tbW9kYXRlIHN1Y2guPGJyPg0KLS0tIEFs ZXg8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IE5ldGNvbmYgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxm IE9mIFBoaWwgU2hhZmVyPGJyPg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE1IDEw OjMyIEFNPGJyPg0KVG86IEtlbnQgV2F0c2VuPGJyPg0KQ2M6IFJvaGl0IFIgUmFuYWRlOyA8YSBo cmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0 Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBOb3RpZmljYXRpb24gdXBkYXRp b24gUkZDIDUyNzc8YnI+DQo8YnI+DQpLZW50IFdhdHNlbiB3cml0ZXM6PGJyPg0KJmd0OyZndDtO b3Qgd2l0aCBSRkMgNTI3NyAtIHRoZXJlIGlzIG5vIGRlbGV0ZS1zdWJzY3JpcHRpb24gaW4gUkZD IDUyNzcuPGJyPg0KJmd0O1Bvb3IgbWFuJ3MgZGVsZXRlOiBkcm9wIHRoZSB1bmRlcmx5aW5nIE5F VENPTkYgc2Vzc2lvbi48YnI+DQo8YnI+DQo7Xik8YnI+DQo8YnI+DQomZ3Q7VGhlIGFzc3VtcHRp b24gaXM8YnI+DQomZ3Q7dGhhdCB0aGVyZSBpcyBhIGRlZGljYXRlZCBORVRDT05GIHNlc3Npb24g Zm9yIGVhY2ggc3Vic2NyaXB0aW9uIChubzxicj4NCiZndDtpbnRlcmxlYXZpbmcpLiZuYnNwOyBV c2luZyBTU0ggY2hhbm5lbHMsIHRoaXMgY2FuIGJlIGEgZmFpcmx5IGNoZWFwPGJyPg0KJmd0O29w ZXJhdGlvbiwgcmV1c2luZyB0aGUgc2FtZSB1bmRlcmx5aW5nIFNTSCBjb25uZWN0aW9uLjxicj4N Cjxicj4NCklmIHdlIGNvdWxkIGhhdmUgbWFkZSB0aGF0IGFzc3VtcHRpb24sIHRoZSBub3RpZmlj YXRpb24gbWVjaGFuaXNtIHdvdWxkIGhhdmUgYmVlbiBvaC1zbyBlYXN5LiZuYnNwOyBJbnN0ZWFk IHdlIGRlc2lnbmVkIGZvciBpbnRlcmxlYXZpbmcgbm90aWZpY2F0aW9ucyBhbmQgJmx0O3JwYy1y ZXBseSZndDtzLiZuYnNwOyBJIHRoaW5nIGl0J3MgdG9vIGxhdGUgdG8gc3RhcnQgcmVxdWlyaW5n IHRoYXQgYXNzdW1wdGlvbiAodW5sZXNzIHdlIHdhbnQgdG8gcmVkZXNpZ24gbm90aWZpY2F0aW9u cw0KICh3aGljaCB3b3VsZCBiZSBhIGdyZWF0IGlkZWEgKGV4Y2VwdCBmb3IgbXkgcHJldmlvdXMg Y29tbWVudHMgcmU6PGJyPg0Kc3RhYmlsaXR5IGFuZCAmcXVvdDtkb25lJnF1b3Q7LW5lc3MpKSku PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCiZuYnNwO1BoaWw8YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5OZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5OZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJy IGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4tLQ0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkFtYmlrYSBQcmFzYWQgVHJpcGF0aHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2VsbCBAPGEgaHJlZj0idGVsOiUyQjkxJTIw OTQzNzU0NzczMCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7OTEgOTQzNzU0NzczMDwvYT4vPGEgaHJl Zj0idGVsOjg1NTMwNzA4NjYiIHRhcmdldD0iX2JsYW5rIj44NTUzMDcwODY2PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHQgZW1haWw6 DQo8YSBocmVmPSJtYWlsdG86YW1iaWthX3RyaXBhdGh5QHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmFtYmlrYV90cmlwYXRoeUB5YWhvby5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Im1haWx0bzphbWJpa2EudHJp cGF0aHlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW1iaWthLnRyaXBhdGh5QGdtYWlsLmNv bTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+c2t5cGU6YW1iaWthX25ldGhhd2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFtYmlrYSBQcmFzYWQgVHJpcGF0aHk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNlbGwgQCYj NDM7OTEgOTQzNzU0NzczMC84NTUzMDcwODY2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHQgZW1haWw6IDxhIGhyZWY9Im1haWx0bzphbWJpa2Ff dHJpcGF0aHlAeWFob28uY29tIiB0YXJnZXQ9Il9ibGFuayI+DQphbWJpa2FfdHJpcGF0aHlAeWFo b28uY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0ibWFpbHRvOmFtYmlrYS50cmlwYXRoeUBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5hbWJpa2EudHJpcGF0aHlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2t5cGU6YW1iaWthX25ldGhhd2s8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_991B70D8B4112A4699D5C00DDBBF878A671E3384szxeml512mbschi_-- From nobody Tue Feb 17 02:26:14 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435671A6F38 for ; Tue, 17 Feb 2015 02:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNuGwWHfy4cz for ; Tue, 17 Feb 2015 02:26:08 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C52E1A1A94 for ; Tue, 17 Feb 2015 02:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33598; q=dns/txt; s=iport; t=1424168768; x=1425378368; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=56CrFUpDqNIY630ieQklZMpGFsha0xGu66qZaCWfotE=; b=PHF6QVRrztffrcCl3XFa89PkbKCQ+H79P7oOS1g+vadwUVOeFg9fVhnZ mLQN0IzQtvApiDnQPhScwHwDrZj2zQf27e81b/4l3KOER7/NO3DipbM6F Gsa4W8+61Sk0h+zYOMIIfOJ36Nsp6fy+KLSSxqTW7U7O+Ii88X5bQxMky M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DQBQCOFuNU/40NJK1bgkNDUloEgn+vbI0ygiABCYJugjlKAhx2QwEBAQEBAXyEDAEBAQQBAQEgBAZBCQIMBAIBCBEEAQELAxMHAwICAh8GCxMBCQgCBAENBQgTiAADEQ23QZIpDYU+AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLD4E9gQeBSAoGAgEeFhcEBgEGgmIugRQFhFYKh1uBEYFsg1eEGgaCWIsuQ4JGgz4iggIcgVBvgQJCfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,593,1418083200"; d="scan'208,217";a="396775980" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP; 17 Feb 2015 10:26:06 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1HAQ6wr020638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 10:26:06 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 04:26:06 -0600 From: "Ambika Prasad Tripathy (ambtripa)" To: Rohit R Ranade , Ambika Tripathy Thread-Topic: [Netconf] Notification updation RFC 5277 Thread-Index: AdAdmGPAceznqgnXSje9O6PD47W4GwKspEggBix6hTAAH2fEgAAEnTgAAABOrQAAAoyGgAAC/EgAAAuCRIABZlQiAAAGeg6AAAGjeAAAxxETAAAA7ToAAAQCRmA= Date: Tue, 17 Feb 2015 10:26:05 +0000 Message-ID: <3B675C3A8DF102408C754E30986E43CF10FB3AF3@xmb-aln-x08.cisco.com> References: <201502051831.t15IVw5U056876@idle.juniper.net> <991B70D8B4112A4699D5C00DDBBF878A671E3249@szxeml512-mbs.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A671E3262@szxeml512-mbs.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A671E3384@szxeml512-mbs.china.huawei.com> In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671E3384@szxeml512-mbs.china.huawei.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.99] Content-Type: multipart/alternative; boundary="_000_3B675C3A8DF102408C754E30986E43CF10FB3AF3xmbalnx08ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 10:26:11 -0000 --_000_3B675C3A8DF102408C754E30986E43CF10FB3AF3xmbalnx08ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIFJvaGl0Lg0KDQpCciwNCkFtYmlrYQ0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9oaXQgUiBSYW5hZGUNClNlbnQ6IFR1 ZXNkYXksIEZlYnJ1YXJ5IDE3LCAyMDE1IDExOjUwIEFNDQpUbzogQW1iaWthIFRyaXBhdGh5DQpD YzogbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBOb3RpZmljYXRpb24g dXBkYXRpb24gUkZDIDUyNzcNCg0KSGksDQoNCi0gbXVsdGlwbGUgY3JlYXRlLXN1YnNjcmlwdGlv biByZXF1ZXN0IGluIHNhbWUgTmV0Q29uZiBzc2ggc2Vzc2lvbiB1c2luZyBkaWZmZXJlbnQgY2hh bm5lbHMuIEJhc2ljYWxseSBtdWx0aXBsZXhpbmcgdGhlIHNhbWUgTmV0Q29uZiBzc2ggc2Vzc2lv biB3aXRoIG11bHRpcGxlIHNzaCBjaGFubmVsLg0KLS0+IFRoaXMgcG9pbnQgSSBkaWQgbm90IHVu ZGVyc3RhbmQuIERvIHlvdSBtZWFuLCB0aGF0IHRoZXJlIHdpbGwgYmUgbXVsdGlwbGUgU1NIIHNl c3Npb25zIHdpdGggc2luZ2xlIE5FVENPTkZTIHNlc3Npb24gPw0KSSBndWVzcyB5b3VyIGludGVu dGlvbiBpcyB0aGF0IHlvdSB3YW50IHRvIHN1YnNldCBlYWNoIG5vdGlmaWNhdGlvbiwgYW5kIHdh bnQgdG8gZ2V0IHRob3NlIHN1YnNldHMgaW4gZGlmZmVyZW50IFNTSCBjaGFubmVsIGZvciBsb2Fk IGJhbGFuY2luZyA/DQoNCldpdGggUmVnYXJkcywNClJvaGl0DQoNCkZyb206IEFtYmlrYSBUcmlw YXRoeSBbbWFpbHRvOmFtYmlrYS50cmlwYXRoeUBnbWFpbC5jb21dDQpTZW50OiAxNyBGZWJydWFy eSwgMjAxNSAxMToyNA0KVG86IFJvaGl0IFIgUmFuYWRlDQpDYzogQWxleGFuZGVyIENsZW1tIChh bGV4KTsgUGhpbCBTaGFmZXI7IEtlbnQgV2F0c2VuOyBuZXRjb25mQGlldGYub3JnPG1haWx0bzpu ZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBOb3RpZmljYXRpb24gdXBk YXRpb24gUkZDIDUyNzcNCg0KSGkgUm9oaXQsDQoNCkZldyB0aG91Z2h0cw0KLSBUaGUgZGF0YXN0 b3JlIHB1c2ggcmVxdWlyZW1lbnRzIGFyZSBwcmVzZW50IGluIGRhdGFzdG9yZS1wdXNoIGRyYWZ0 IHlvdSBzdGF0ZWQgYWJvdmUgYW5kIHNlY3Rpb24gMyBnaXZlcyBtb3JlIGNsZWFyIGlkZWEuDQot IEFsb25nIHdpdGggdGhpcywgZmV3IG1vcmUgcmVxdWlyZW1lbnRzIGkgdGhpbmsgZm9yIE5ldENv bmYgbm90aWZpY2F0aW9uIGNhbiBiZSAgaGFuZGxlZC4NCiAgIC0gbXVsdGlwbGUgY3JlYXRlLXN1 YnNjcmlwdGlvbiByZXF1ZXN0IGluIHNhbWUgTmV0Q29uZiBzc2ggc2Vzc2lvbiB1c2luZyBkaWZm ZXJlbnQgY2hhbm5lbHMuIEJhc2ljYWxseSBtdWx0aXBsZXhpbmcgdGhlIHNhbWUgTmV0Q29uZiBz c2ggc2Vzc2lvbiB3aXRoIG11bHRpcGxlIHNzaCBjaGFubmVsLg0KICAgLSB0aGVyZSBzaG91bGQg YmUgYSB3YXkgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRp b24gYW5kIGRhdGEgc3Vic2NyaXB0aW9uLg0KICAgLSBlYWNoIHN1YnNjcmlwdGlvbiBjaGFubmVs IGNhbiBiZSB0cmVhdGVkIGluZGVwZW5kZW50bHkgYW5kIGFueSBvbmUgc3Vic2NyaXB0aW9uIHRl cm1pbmF0aW9uIHNob3VsZG4ndCBhZmZlY3Qgc2Vzc2lvbi4NCg0KYnIsDQpBbWJpa2EgUHJhc2Fk IFRyaXBhdGh5DQoNCg0KT24gRnJpLCBGZWIgMTMsIDIwMTUgYXQgMTI6MjMgUE0sIFJvaGl0IFIg UmFuYWRlIDxyb2hpdHJyYW5hZGVAaHVhd2VpLmNvbTxtYWlsdG86cm9oaXRycmFuYWRlQGh1YXdl aS5jb20+PiB3cm90ZToNCkhpLA0KDQpBcyBwZXIgeW91ciBtYWlsIGFib3V0IERhdGFzdG9yZS1w dXNoLCBJIHJlZmVycmVkIHRvIHRoZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bmV0bW9kLWNsZW1tLWRhdGFzdG9yZS1wdXNoLTAwIGRyYWZ0IG9mIGRhdGFzdG9yZS1wdXNoLg0K S2luZGx5IHByb3ZpZGUgdGhlIHJlcXVpcmVtZW50cyBvZiBkYXRhLXN0b3JlLXB1c2ggdGhhdCBu ZWVkcyB0byBiZSBhZGRlZCggdGhhdCB5b3UgY3VycmVudGx5IGhhdmUgaW4gbWluZGVkKSB0byB0 aGUgZXh0ZW5zaW9uLiBJIGhhdmUgYSBzY2VuYXJpbywgd2hlcmUgbWF5YmUgZGF0YXN0b3JlLXB1 c2ggYWxzbyBtaWdodCBiZSBuZWNlc3NhcnkgZm9yIG15IGNsaWVudC4NCk1heWJlIGJhc2VkIG9u IHlvdXIgdGhvdWdodHMgbWF5YmUgSSBjYW4gYWxzbyBhZGQgdG8gdGhvc2UgcmVxdWlyZW1lbnRz Lg0KDQpXaXRoIFJlZ2FyZHMsDQpSb2hpdA0KDQpGcm9tOiBBbWJpa2EgVHJpcGF0aHkgW21haWx0 bzphbWJpa2EudHJpcGF0aHlAZ21haWwuY29tPG1haWx0bzphbWJpa2EudHJpcGF0aHlAZ21haWwu Y29tPl0NClNlbnQ6IDEzIEZlYnJ1YXJ5LCAyMDE1IDExOjM3DQpUbzogUm9oaXQgUiBSYW5hZGUN CkNjOiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBQaGlsIFNoYWZlcjsgS2VudCBXYXRzZW47IG5l dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBb TmV0Y29uZl0gTm90aWZpY2F0aW9uIHVwZGF0aW9uIFJGQyA1Mjc3DQoNCkhpLCBUaGUgZXhpc3Rp bmcgTmV0Q29uZiBzZXNzaW9uIHdpdGggbm90aWZpY2F0aW9uIGRlZmluaXRpb24gYXMgcGVyIHJm YzUyNzcgaXMgdmVyeSBsaW1pdGVkIHRvIGp1c3Qgb25jZSBzdWJzY3JpcHRpb24gZm9yIGFsbCBl dmVudCBpbiB0aGUgc3lzdGVtLiBGb3IgZGlmZmVyZW50IGZpbHRlcnMgaW4gbm90aWZpY2F0aW9u LCB0aGVyZSBpcyBhIG5lZWQgdG8gY3JlYXRlIGRpZmZlcmVudCBzZXNzaW9uIGFuZCB3aXRoIHVu aXF1ZSBzdWJzY3JpcHRpb24gcmVxdWVzdC4gVGhpcyBpcyBub3QgYSBlZmZpY2llbnQgc29sdXRp b24uDQpUaGUgbWVjaGFuaXNtIHNob3VsZCBhbGxvdyBtdWx0aXBsZSB1bmlxdWUgY3JlYXRlLXN1 YnNjcmlwdGlvbiByZXF1ZXN0IGluIGEgc2Vzc2lvbiBhbmQgc2VuZCB0aGUgZXZlbnQgZGF0YSBi YXNlZCBvbiBzdWJzY3JpcHRpb24gcmVxdWVzdCBhbmQgdGhlIHN1YnNjcmlwdGlvbiBzaG91bGQg IGJlIHVuaXF1ZWx5IGlkZW50aWZpZWQgYnkgb25lIHN1YnNjcmlwdGlvbi1pZCBmb3IgZWFzeSBt YW5hZ2VtZW50IGxpa2UgUlBDLCBSUEMtcmVwbHkuDQoNClRoZSBjdXJyZW50IHdheSBvZiBoYW5k bGluZyBub3RpZmljYXRpb24gaXMgdmVyeSBsaW1pdGVkIHRvIFBVQi1TVUIgbWVjaGFuaXNtIGFs c28gYW5kIG5vdCBlZmZpY2llbnQgc29sdXRpb24uIElmIHRoZXJlIHdpbGwgYmUgb25lIGV4dGVu c2lvbiB0byBub3RpZmljYXRpb24gbWVjaGFuaXNtIHRvIGhhbmRsZSBQVUItU1VCIGRhdGEsIGJ5 IGFkZHJlc3NpbmcgYWxsIHJlcXVpcmVtZW50cyBvZiBkYXRhc3RvcmUtcHVzaCB3aWxsIGhlbHAg YSBsb3QuDQoNCmJyLA0KQW1iaWthIFByYXNhZCBUcmlwYXRoeQ0KDQpPbiBGcmksIEZlYiAxMywg MjAxNSBhdCA4OjMxIEFNLCBSb2hpdCBSIFJhbmFkZSA8cm9oaXRycmFuYWRlQGh1YXdlaS5jb208 bWFpbHRvOnJvaGl0cnJhbmFkZUBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSwgSXMgdGhlcmUgYW55 IHVwZGF0ZSBvbiB0aGlzID8gUHJlZmVyYWJseSBhIHNvbHV0aW9uIHdoaWNoIGRvZXMgbm90IGlu dm9sdmUgdGVhcmluZyBkb3duIGFuZCBicmluZ2luZyB1cCBhIHNlc3Npb24gd2lsbCBiZSB3ZWxj b21lLg0KVGhlIG5vdGlmaWNhdGlvbnMgbG9zdCBkdXJpbmcgdGhlIHRpbWUgcGVyaW9kIGZvciB3 aGljaCB0aGUgc2Vzc2lvbiBpcyBkb3duLiBBIHNlcGFyYXRlIG1lY2hhbmlzbSB0byBiZSB1c2Vk IHRvIGdldCB0aGVtIGJhY2sgYW5kIHRoZSBzdWJzZXF1ZW50IGhhbmRsaW5nIHdpbGwgbWFrZSBp dCB2ZXJ5IGNvbXBsaWNhdGVkLg0KS2luZGx5IGhlbHAuDQoNCldpdGggUmVnYXJkcywNClJvaGl0 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4YW5kZXIgQ2xlbW0gKGFs ZXgpIFttYWlsdG86YWxleEBjaXNjby5jb208bWFpbHRvOmFsZXhAY2lzY28uY29tPl0NClNlbnQ6 IDA2IEZlYnJ1YXJ5LCAyMDE1IDAwOjQxDQpUbzogUGhpbCBTaGFmZXI7IEtlbnQgV2F0c2VuDQpD YzogUm9oaXQgUiBSYW5hZGU7IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSRTogW05ldGNvbmZdIE5vdGlmaWNhdGlvbiB1cGRhdGlvbiBSRkMgNTI3 Nw0KDQpTdGFiaWxpdHkgaXMgYWxsIGdvb2QsIGFzc3VtaW5nIGl0IGNhbiBiZSByZWFzb25hYmx5 IGFkYXB0ZWQgdG8gcmVxdWlyZW1lbnRzLiAgVGhlIG90aGVyIHNpZGUgb2YgdGhlIHN0YWJpbGl0 eSBjb2luIHdvdWxkIGJlIGluZmxleGliaWxpdHkuDQpUaGUgbmVlZCB0byBhZGp1c3Qgc3Vic2Ny aXB0aW9ucyBhcHBlYXJzIGZhaXJseSByZWFzb25hYmxlOyB3ZSBhcmUgYWxzbyBzZWVpbmcgdGhp cyBpbiBjb25qdW5jdGlvbiB3aXRoIGRhdGFzdG9yZS1wdXNoLiAgU28sIEkgZm9yIG9uZSB3b3Vs ZCB0aGluayBpdCByZWFzb25hYmxlIHRvIGxvb2sgaW50byBleHRlbnNpb25zIHRvIGFjY29tbW9k YXRlIHN1Y2guDQotLS0gQWxleA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25m LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUGhpbCBTaGFmZXINClNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSAwNSwgMjAxNSAxMDozMiBBTQ0KVG86IEtlbnQgV2F0c2VuDQpDYzogUm9o aXQgUiBSYW5hZGU7IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW05ldGNvbmZdIE5vdGlmaWNhdGlvbiB1cGRhdGlvbiBSRkMgNTI3Nw0KDQpL ZW50IFdhdHNlbiB3cml0ZXM6DQo+Pk5vdCB3aXRoIFJGQyA1Mjc3IC0gdGhlcmUgaXMgbm8gZGVs ZXRlLXN1YnNjcmlwdGlvbiBpbiBSRkMgNTI3Ny4NCj5Qb29yIG1hbidzIGRlbGV0ZTogZHJvcCB0 aGUgdW5kZXJseWluZyBORVRDT05GIHNlc3Npb24uDQoNCjteKQ0KDQo+VGhlIGFzc3VtcHRpb24g aXMNCj50aGF0IHRoZXJlIGlzIGEgZGVkaWNhdGVkIE5FVENPTkYgc2Vzc2lvbiBmb3IgZWFjaCBz dWJzY3JpcHRpb24gKG5vDQo+aW50ZXJsZWF2aW5nKS4gIFVzaW5nIFNTSCBjaGFubmVscywgdGhp cyBjYW4gYmUgYSBmYWlybHkgY2hlYXANCj5vcGVyYXRpb24sIHJldXNpbmcgdGhlIHNhbWUgdW5k ZXJseWluZyBTU0ggY29ubmVjdGlvbi4NCg0KSWYgd2UgY291bGQgaGF2ZSBtYWRlIHRoYXQgYXNz dW1wdGlvbiwgdGhlIG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gd291bGQgaGF2ZSBiZWVuIG9oLXNv IGVhc3kuICBJbnN0ZWFkIHdlIGRlc2lnbmVkIGZvciBpbnRlcmxlYXZpbmcgbm90aWZpY2F0aW9u cyBhbmQgPHJwYy1yZXBseT5zLiAgSSB0aGluZyBpdCdzIHRvbyBsYXRlIHRvIHN0YXJ0IHJlcXVp cmluZyB0aGF0IGFzc3VtcHRpb24gKHVubGVzcyB3ZSB3YW50IHRvIHJlZGVzaWduIG5vdGlmaWNh dGlvbnMgKHdoaWNoIHdvdWxkIGJlIGEgZ3JlYXQgaWRlYSAoZXhjZXB0IGZvciBteSBwcmV2aW91 cyBjb21tZW50cyByZToNCnN0YWJpbGl0eSBhbmQgImRvbmUiLW5lc3MpKSkuDQoNClRoYW5rcywN CiBQaGlsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29u ZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KDQoNCi0t DQpBbWJpa2EgUHJhc2FkIFRyaXBhdGh5DQpDZWxsIEArOTEgOTQzNzU0NzczMDx0ZWw6JTJCOTEl MjA5NDM3NTQ3NzMwPi84NTUzMDcwODY2PHRlbDo4NTUzMDcwODY2Pg0KQWx0IGVtYWlsOiBhbWJp a2FfdHJpcGF0aHlAeWFob28uY29tPG1haWx0bzphbWJpa2FfdHJpcGF0aHlAeWFob28uY29tPg0K YW1iaWthLnRyaXBhdGh5QGdtYWlsLmNvbTxtYWlsdG86YW1iaWthLnRyaXBhdGh5QGdtYWlsLmNv bT4NCnNreXBlOmFtYmlrYV9uZXRoYXdrDQoNCg0KDQotLQ0KQW1iaWthIFByYXNhZCBUcmlwYXRo eQ0KQ2VsbCBAKzkxIDk0Mzc1NDc3MzAvODU1MzA3MDg2Ng0KQWx0IGVtYWlsOiBhbWJpa2FfdHJp cGF0aHlAeWFob28uY29tPG1haWx0bzphbWJpa2FfdHJpcGF0aHlAeWFob28uY29tPg0KYW1iaWth LnRyaXBhdGh5QGdtYWlsLmNvbTxtYWlsdG86YW1iaWthLnRyaXBhdGh5QGdtYWlsLmNvbT4NCnNr eXBlOmFtYmlrYV9uZXRoYXdrDQo= --_000_3B675C3A8DF102408C754E30986E43CF10FB3AF3xmbalnx08ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5ZZXMgUm9oaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Cciw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QW1iaWthPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTmV0Y29uZiBbbWFp bHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9oaXQg UiBSYW5hZGU8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMTcsIDIwMTUgMTE6 NTAgQU08YnI+DQo8Yj5Ubzo8L2I+IEFtYmlrYSBUcmlwYXRoeTxicj4NCjxiPkNjOjwvYj4gbmV0 Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIE5vdGlmaWNh dGlvbiB1cGRhdGlvbiBSRkMgNTI3NzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIG11bHRpcGxlIGNyZWF0 ZS1zdWJzY3JpcHRpb24gcmVxdWVzdCBpbiBzYW1lIE5ldENvbmYgc3NoIHNlc3Npb24gdXNpbmcg ZGlmZmVyZW50IGNoYW5uZWxzLiBCYXNpY2FsbHkgbXVsdGlwbGV4aW5nIHRoZSBzYW1lIE5ldENv bmYgc3NoIHNlc3Npb24gd2l0aCBtdWx0aXBsZSBzc2ggY2hhbm5lbC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3Mi PsOgPC9zcGFuPiBUaGlzIHBvaW50IEkgZGlkIG5vdCB1bmRlcnN0YW5kLiBEbyB5b3UgbWVhbiwg dGhhdCB0aGVyZSB3aWxsIGJlIG11bHRpcGxlIFNTSCBzZXNzaW9ucyB3aXRoIHNpbmdsZSBORVRD T05GUyBzZXNzaW9uID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vl c3MgeW91ciBpbnRlbnRpb24gaXMgdGhhdCB5b3Ugd2FudCB0byBzdWJzZXQgZWFjaCBub3RpZmlj YXRpb24sIGFuZCB3YW50IHRvIGdldCB0aG9zZSBzdWJzZXRzIGluIGRpZmZlcmVudCBTU0ggY2hh bm5lbCBmb3IgbG9hZCBiYWxhbmNpbmcgPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIFJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb2hpdDxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFtYmlrYSBU cmlwYXRoeSBbPGEgaHJlZj0ibWFpbHRvOmFtYmlrYS50cmlwYXRoeUBnbWFpbC5jb20iPm1haWx0 bzphbWJpa2EudHJpcGF0aHlAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxNyBG ZWJydWFyeSwgMjAxNSAxMToyNDxicj4NCjxiPlRvOjwvYj4gUm9oaXQgUiBSYW5hZGU8YnI+DQo8 Yj5DYzo8L2I+IEFsZXhhbmRlciBDbGVtbSAoYWxleCk7IFBoaWwgU2hhZmVyOyBLZW50IFdhdHNl bjsgPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPg0KbmV0Y29uZkBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSBOb3RpZmljYXRpb24gdXBkYXRp b24gUkZDIDUyNzc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIFJvaGl0LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RmV3IHRob3VnaHRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tIFRoZSBkYXRhc3RvcmUgcHVzaCByZXF1aXJlbWVudHMgYXJlIHByZXNlbnQgaW4g ZGF0YXN0b3JlLXB1c2ggZHJhZnQgeW91IHN0YXRlZCBhYm92ZSBhbmQgc2VjdGlvbiAzIGdpdmVz IG1vcmUgY2xlYXIgaWRlYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0gQWxvbmcgd2l0aCB0aGlzLCBmZXcgbW9yZSByZXF1aXJlbWVudHMgaSB0 aGluayBmb3IgTmV0Q29uZiBub3RpZmljYXRpb24gY2FuIGJlICZuYnNwO2hhbmRsZWQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7LSBtdWx0aXBsZSBjcmVhdGUtc3Vic2NyaXB0aW9uIHJlcXVlc3QgaW4gc2FtZSBOZXRDb25m IHNzaCBzZXNzaW9uIHVzaW5nIGRpZmZlcmVudCBjaGFubmVscy4gQmFzaWNhbGx5IG11bHRpcGxl eGluZyB0aGUgc2FtZSBOZXRDb25mIHNzaCBzZXNzaW9uIHdpdGggbXVsdGlwbGUgc3NoIGNoYW5u ZWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7LSB0aGVyZSBzaG91bGQgYmUgYSB3YXkgdG8gZGlmZmVyZW50aWF0ZSBiZXR3 ZWVuIG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gYW5kIGRhdGEgc3Vic2NyaXB0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwOy0gZWFjaCBzdWJzY3JpcHRpb24gY2hhbm5lbCBjYW4gYmUgdHJlYXRlZCBpbmRlcGVuZGVu dGx5IGFuZCBhbnkgb25lIHN1YnNjcmlwdGlvbiB0ZXJtaW5hdGlvbiBzaG91bGRuJ3QgYWZmZWN0 IHNlc3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5iciw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFtYmlrYSBQcmFzYWQgVHJpcGF0aHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiAxMywgMjAxNSBh dCAxMjoyMyBQTSwgUm9oaXQgUiBSYW5hZGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2hpdHJyYW5h ZGVAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvaGl0cnJhbmFkZUBodWF3ZWkuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkFzIHBlciB5b3VyIG1haWwgYWJvdXQgRGF0YXN0b3JlLXB1c2gsIEkgcmVm ZXJyZWQgdG8gdGhlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bmV0bW9kLWNsZW1tLWRhdGFzdG9yZS1wdXNoLTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbmV0bW9kLWNsZW1tLWRhdGFzdG9yZS1wdXNoLTAw PC9hPiBkcmFmdCBvZiBkYXRhc3RvcmUtcHVzaC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPktpbmRseSBwcm92aWRlIHRoZSByZXF1aXJlbWVudHMgb2YgZGF0YS1zdG9yZS1wdXNo IHRoYXQgbmVlZHMgdG8gYmUgYWRkZWQoIHRoYXQgeW91IGN1cnJlbnRseSBoYXZlDQogaW4gbWlu ZGVkKSB0byB0aGUgZXh0ZW5zaW9uLiBJIGhhdmUgYSBzY2VuYXJpbywgd2hlcmUgbWF5YmUgZGF0 YXN0b3JlLXB1c2ggYWxzbyBtaWdodCBiZSBuZWNlc3NhcnkgZm9yIG15IGNsaWVudC4NCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1heWJlIGJhc2VkIG9uIHlvdXIgdGhvdWdodHMg bWF5YmUgSSBjYW4gYWxzbyBhZGQgdG8gdGhvc2UgcmVxdWlyZW1lbnRzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PldpdGggUmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb2hpdDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IEFtYmlrYSBUcmlwYXRoeSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphbWJp a2EudHJpcGF0aHlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW1iaWthLnRyaXBhdGh5QGdt YWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTMgRmVicnVhcnksIDIwMTUgMTE6Mzc8 YnI+DQo8Yj5Ubzo8L2I+IFJvaGl0IFIgUmFuYWRlPGJyPg0KPGI+Q2M6PC9iPiBBbGV4YW5kZXIg Q2xlbW0gKGFsZXgpOyBQaGlsIFNoYWZlcjsgS2VudCBXYXRzZW47IDxhIGhyZWY9Im1haWx0bzpu ZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpuZXRjb25mQGlldGYub3JnPC9hPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gTm90aWZpY2F0aW9uIHVwZGF0aW9u IFJGQyA1Mjc3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSwgVGhlIGV4aXN0aW5nIE5ldENvbmYgc2Vzc2lv biB3aXRoIG5vdGlmaWNhdGlvbiBkZWZpbml0aW9uIGFzIHBlciByZmM1Mjc3IGlzIHZlcnkgbGlt aXRlZCB0byBqdXN0IG9uY2Ugc3Vic2NyaXB0aW9uIGZvciBhbGwgZXZlbnQgaW4gdGhlIHN5c3Rl bS4gRm9yIGRpZmZlcmVudCBmaWx0ZXJzIGluIG5vdGlmaWNhdGlvbiwNCiB0aGVyZSBpcyBhIG5l ZWQgdG8gY3JlYXRlIGRpZmZlcmVudCBzZXNzaW9uIGFuZCB3aXRoIHVuaXF1ZSBzdWJzY3JpcHRp b24gcmVxdWVzdC4gVGhpcyBpcyBub3QgYSBlZmZpY2llbnQgc29sdXRpb24uJm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgbWVjaGFuaXNtIHNo b3VsZCBhbGxvdyBtdWx0aXBsZSB1bmlxdWUgY3JlYXRlLXN1YnNjcmlwdGlvbiByZXF1ZXN0IGlu IGEgc2Vzc2lvbiBhbmQgc2VuZCB0aGUgZXZlbnQgZGF0YSBiYXNlZCBvbiBzdWJzY3JpcHRpb24g cmVxdWVzdCBhbmQgdGhlIHN1YnNjcmlwdGlvbiBzaG91bGQgJm5ic3A7YmUgdW5pcXVlbHkNCiBp ZGVudGlmaWVkIGJ5IG9uZSBzdWJzY3JpcHRpb24taWQgZm9yIGVhc3kgbWFuYWdlbWVudCBsaWtl IFJQQywgUlBDLXJlcGx5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGUgY3VycmVudCB3YXkgb2YgaGFuZGxpbmcgbm90aWZpY2F0aW9uIGlzIHZlcnkg bGltaXRlZCB0byBQVUItU1VCIG1lY2hhbmlzbSBhbHNvIGFuZCBub3QgZWZmaWNpZW50IHNvbHV0 aW9uLiBJZiB0aGVyZSB3aWxsIGJlIG9uZSBleHRlbnNpb24gdG8gbm90aWZpY2F0aW9uIG1lY2hh bmlzbSB0byBoYW5kbGUNCiBQVUItU1VCIGRhdGEsIGJ5IGFkZHJlc3NpbmcgYWxsIHJlcXVpcmVt ZW50cyBvZiBkYXRhc3RvcmUtcHVzaCB3aWxsIGhlbHAgYSBsb3QuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ YnIsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkFtYmlrYSBQcmFzYWQgVHJpcGF0aHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgRmViIDEzLCAyMDE1IGF0IDg6MzEgQU0s IFJvaGl0IFIgUmFuYWRlICZsdDs8YSBocmVmPSJtYWlsdG86cm9oaXRycmFuYWRlQGh1YXdlaS5j b20iIHRhcmdldD0iX2JsYW5rIj5yb2hpdHJyYW5hZGVAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSwgSXMgdGhlcmUgYW55 IHVwZGF0ZSBvbiB0aGlzID8gUHJlZmVyYWJseSBhIHNvbHV0aW9uIHdoaWNoIGRvZXMgbm90IGlu dm9sdmUgdGVhcmluZyBkb3duIGFuZCBicmluZ2luZyB1cCBhIHNlc3Npb24gd2lsbCBiZSB3ZWxj b21lLjxicj4NClRoZSBub3RpZmljYXRpb25zIGxvc3QgZHVyaW5nIHRoZSB0aW1lIHBlcmlvZCBm b3Igd2hpY2ggdGhlIHNlc3Npb24gaXMgZG93bi4gQSBzZXBhcmF0ZSBtZWNoYW5pc20gdG8gYmUg dXNlZCB0byBnZXQgdGhlbSBiYWNrIGFuZCB0aGUgc3Vic2VxdWVudCBoYW5kbGluZyB3aWxsIG1h a2UgaXQgdmVyeSBjb21wbGljYXRlZC48YnI+DQpLaW5kbHkgaGVscC48YnI+DQo8YnI+DQpXaXRo IFJlZ2FyZHMsPGJyPg0KUm9oaXQ8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IEFsZXhhbmRlciBDbGVtbSAoYWxleCkgW21haWx0bzo8YSBocmVmPSJtYWls dG86YWxleEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5hbGV4QGNpc2NvLmNvbTwvYT5dPGJy Pg0KU2VudDogMDYgRmVicnVhcnksIDIwMTUgMDA6NDE8YnI+DQpUbzogUGhpbCBTaGFmZXI7IEtl bnQgV2F0c2VuPGJyPg0KQ2M6IFJvaGl0IFIgUmFuYWRlOyA8YSBocmVmPSJtYWlsdG86bmV0Y29u ZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3ViamVjdDogUkU6 IFtOZXRjb25mXSBOb3RpZmljYXRpb24gdXBkYXRpb24gUkZDIDUyNzc8YnI+DQo8YnI+DQpTdGFi aWxpdHkgaXMgYWxsIGdvb2QsIGFzc3VtaW5nIGl0IGNhbiBiZSByZWFzb25hYmx5IGFkYXB0ZWQg dG8gcmVxdWlyZW1lbnRzLiZuYnNwOyBUaGUgb3RoZXIgc2lkZSBvZiB0aGUgc3RhYmlsaXR5IGNv aW4gd291bGQgYmUgaW5mbGV4aWJpbGl0eS48YnI+DQpUaGUgbmVlZCB0byBhZGp1c3Qgc3Vic2Ny aXB0aW9ucyBhcHBlYXJzIGZhaXJseSByZWFzb25hYmxlOyB3ZSBhcmUgYWxzbyBzZWVpbmcgdGhp cyBpbiBjb25qdW5jdGlvbiB3aXRoIGRhdGFzdG9yZS1wdXNoLiZuYnNwOyBTbywgSSBmb3Igb25l IHdvdWxkIHRoaW5rIGl0IHJlYXNvbmFibGUgdG8gbG9vayBpbnRvIGV4dGVuc2lvbnMgdG8gYWNj b21tb2RhdGUgc3VjaC48YnI+DQotLS0gQWxleDxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgUGhpbCBTaGFmZXI8YnI+DQpTZW50OiBUaHVy c2RheSwgRmVicnVhcnkgMDUsIDIwMTUgMTA6MzIgQU08YnI+DQpUbzogS2VudCBXYXRzZW48YnI+ DQpDYzogUm9oaXQgUiBSYW5hZGU7IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW05l dGNvbmZdIE5vdGlmaWNhdGlvbiB1cGRhdGlvbiBSRkMgNTI3Nzxicj4NCjxicj4NCktlbnQgV2F0 c2VuIHdyaXRlczo8YnI+DQomZ3Q7Jmd0O05vdCB3aXRoIFJGQyA1Mjc3IC0gdGhlcmUgaXMgbm8g ZGVsZXRlLXN1YnNjcmlwdGlvbiBpbiBSRkMgNTI3Ny48YnI+DQomZ3Q7UG9vciBtYW4ncyBkZWxl dGU6IGRyb3AgdGhlIHVuZGVybHlpbmcgTkVUQ09ORiBzZXNzaW9uLjxicj4NCjxicj4NCjteKTxi cj4NCjxicj4NCiZndDtUaGUgYXNzdW1wdGlvbiBpczxicj4NCiZndDt0aGF0IHRoZXJlIGlzIGEg ZGVkaWNhdGVkIE5FVENPTkYgc2Vzc2lvbiBmb3IgZWFjaCBzdWJzY3JpcHRpb24gKG5vPGJyPg0K Jmd0O2ludGVybGVhdmluZykuJm5ic3A7IFVzaW5nIFNTSCBjaGFubmVscywgdGhpcyBjYW4gYmUg YSBmYWlybHkgY2hlYXA8YnI+DQomZ3Q7b3BlcmF0aW9uLCByZXVzaW5nIHRoZSBzYW1lIHVuZGVy bHlpbmcgU1NIIGNvbm5lY3Rpb24uPGJyPg0KPGJyPg0KSWYgd2UgY291bGQgaGF2ZSBtYWRlIHRo YXQgYXNzdW1wdGlvbiwgdGhlIG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gd291bGQgaGF2ZSBiZWVu IG9oLXNvIGVhc3kuJm5ic3A7IEluc3RlYWQgd2UgZGVzaWduZWQgZm9yIGludGVybGVhdmluZyBu b3RpZmljYXRpb25zIGFuZCAmbHQ7cnBjLXJlcGx5Jmd0O3MuJm5ic3A7IEkgdGhpbmcgaXQncyB0 b28gbGF0ZSB0byBzdGFydCByZXF1aXJpbmcgdGhhdCBhc3N1bXB0aW9uICh1bmxlc3Mgd2Ugd2Fu dCB0byByZWRlc2lnbiBub3RpZmljYXRpb25zDQogKHdoaWNoIHdvdWxkIGJlIGEgZ3JlYXQgaWRl YSAoZXhjZXB0IGZvciBteSBwcmV2aW91cyBjb21tZW50cyByZTo8YnI+DQpzdGFiaWxpdHkgYW5k ICZxdW90O2RvbmUmcXVvdDstbmVzcykpKS48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KJm5ic3A7 UGhpbDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86TmV0 Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 TmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW1iaWthIFByYXNhZCBUcmlwYXRo eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5D ZWxsIEA8YSBocmVmPSJ0ZWw6JTJCOTElMjA5NDM3NTQ3NzMwIiB0YXJnZXQ9Il9ibGFuayI+JiM0 Mzs5MSA5NDM3NTQ3NzMwPC9hPi88YSBocmVmPSJ0ZWw6ODU1MzA3MDg2NiIgdGFyZ2V0PSJfYmxh bmsiPjg1NTMwNzA4NjY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkFsdCBlbWFpbDoNCjxhIGhyZWY9Im1haWx0bzphbWJpa2FfdHJpcGF0 aHlAeWFob28uY29tIiB0YXJnZXQ9Il9ibGFuayI+YW1iaWthX3RyaXBhdGh5QHlhaG9vLmNvbTwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGEgaHJlZj0ibWFpbHRvOmFtYmlrYS50cmlwYXRoeUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5hbWJpa2EudHJpcGF0aHlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5za3lwZTphbWJpa2FfbmV0aGF3azxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNs ZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QW1iaWthIFByYXNhZCBUcmlwYXRoeTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2VsbCBAJiM0Mzs5MSA5NDM3NTQ3NzMwLzg1NTMwNzA4NjY8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdCBlbWFp bDogPGEgaHJlZj0ibWFpbHRvOmFtYmlrYV90cmlwYXRoeUB5YWhvby5jb20iIHRhcmdldD0iX2Js YW5rIj4NCmFtYmlrYV90cmlwYXRoeUB5YWhvby5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86YW1iaWthLnRy aXBhdGh5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFtYmlrYS50cmlwYXRoeUBnbWFpbC5j b208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5za3lwZTphbWJpa2FfbmV0aGF3azxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3B675C3A8DF102408C754E30986E43CF10FB3AF3xmbalnx08ciscoc_-- From nobody Tue Feb 17 03:43: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 E7CCC1A0636 for ; Tue, 17 Feb 2015 03:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK-pubsYoyTP for ; Tue, 17 Feb 2015 03:43:15 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 554461A040B for ; Tue, 17 Feb 2015 03:43:15 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 4EC9512801AA; Tue, 17 Feb 2015 12:43:14 +0100 (CET) Date: Tue, 17 Feb 2015 12:43:14 +0100 (CET) Message-Id: <20150217.124314.1253557840502628376.mbj@tail-f.com> To: ambtripa@cisco.com From: Martin Bjorklund In-Reply-To: <3B675C3A8DF102408C754E30986E43CF10FB3AF3@xmb-aln-x08.cisco.com> References: <991B70D8B4112A4699D5C00DDBBF878A671E3384@szxeml512-mbs.china.huawei.com> <3B675C3A8DF102408C754E30986E43CF10FB3AF3@xmb-aln-x08.cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: rohitrranade@huawei.com, netconf@ietf.org Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 11:43:17 -0000 > >> - multiple create-subscription request in same NetConf ssh session > >> using different channels. Basically multiplexing the same NetConf > >> ssh session with multiple ssh channel. > > --> This point I did not understand. Do you mean, that there will be > > multiple SSH sessions with single NETCONFS session ? > > I guess your intention is that you want to subset each notification, > > and want to get those subsets in different SSH channel for load > > balancing ? > > Yes Rohit. Currently, each SSH channel becomes a separate NETCONF session. So this proposal would require a new binding for NETCONF over SSH, and a concept of "channels" in the base NETCONF protocol. I don't think this is a good idea. /martin From nobody Tue Feb 17 04:27:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC2E1A884E for ; Tue, 17 Feb 2015 04:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1K93M11BnuB for ; Tue, 17 Feb 2015 04:27:06 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 C28571A8847 for ; Tue, 17 Feb 2015 04:27:05 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so41515146igb.0 for ; Tue, 17 Feb 2015 04:27:05 -0800 (PST) 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 :cc:content-type; bh=cvB7yEbBUGzJcegd3PoxGUTzfVcwlpOoZRnR+rJnU7o=; b=X1ETxrVlhyI9Ma63lEyWjUNWQe3ak9f/8BmW+9FB5Ia+9+S6rWvCtv9S+PnJBGwayk pTkrsI9x9f+MoP9fEtxAtvXVADt9iHDmWBf/lYJYSt+LIQUB4iV/zPMB+oCzx7OZ8App ekkI7L5qY2eyPOdSmzz0OYvdibWnEXxmcvnAK7gESyiqGjvpDNgLP+NEJWJpDTlUiVpt 6bzHY0tS+S1G3RVoAsJeicR2yPv91reh1FMsCzYr4w3SBhG4aWdkYhH/3ABoIbNF9Eor J/4xN406vNDlf5RgvPXLfdIlRlRcuDhvHHMIbfRpqXZand7Nw1GO5rG5/HdUDYjxqBsa XPug== MIME-Version: 1.0 X-Received: by 10.50.66.235 with SMTP id i11mr27944900igt.40.1424176025005; Tue, 17 Feb 2015 04:27:05 -0800 (PST) Received: by 10.36.0.15 with HTTP; Tue, 17 Feb 2015 04:27:04 -0800 (PST) In-Reply-To: <20150217.124314.1253557840502628376.mbj@tail-f.com> References: <991B70D8B4112A4699D5C00DDBBF878A671E3384@szxeml512-mbs.china.huawei.com> <3B675C3A8DF102408C754E30986E43CF10FB3AF3@xmb-aln-x08.cisco.com> <20150217.124314.1253557840502628376.mbj@tail-f.com> Date: Tue, 17 Feb 2015 17:57:04 +0530 Message-ID: From: Ambika Tripathy To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bd6be0a11743b050f47d203 Archived-At: Cc: Rohit R Ranade , "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 12:27:07 -0000 --047d7bd6be0a11743b050f47d203 Content-Type: text/plain; charset=UTF-8 Hi, Can you please let me know the reason behind it ? That mean, one netconf session is only limited to only one subscription and the subscription will end with session close. For multiple subscription request the same application needs to create multiple netconf session. Is not it mean, the NetConf is not utilization the complete capability of underlying transport i.e. SSH. br, Ambika Prasad Tripathy On Tue, Feb 17, 2015 at 5:13 PM, Martin Bjorklund wrote: > > > > >> - multiple create-subscription request in same NetConf ssh session > > >> using different channels. Basically multiplexing the same NetConf > > >> ssh session with multiple ssh channel. > > > --> This point I did not understand. Do you mean, that there will be > > > multiple SSH sessions with single NETCONFS session ? > > > I guess your intention is that you want to subset each notification, > > > and want to get those subsets in different SSH channel for load > > > balancing ? > > > > Yes Rohit. > > Currently, each SSH channel becomes a separate NETCONF session. So > this proposal would require a new binding for NETCONF over SSH, and a > concept of "channels" in the base NETCONF protocol. I don't think > this is a good idea. > > > /martin > -- Ambika Prasad Tripathy Cell @+91 9437547730/8553070866 Alt email: ambika_tripathy@yahoo.com ambika.tripathy@gmail.com skype:ambika_nethawk --047d7bd6be0a11743b050f47d203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Can you please let me know th= e reason behind it ?

That mean, one netconf session is o= nly limited to only one subscription and the subscription will end with ses= sion close.
For multiple subscription request the same = application needs to create multiple netconf session.

<= div>Is not it mean, the NetConf is not utilization the complete capability = of underlying transport i.e. SSH.


b= r,
Ambika Prasad Tripathy
<= br>
On Tue, Feb 17, 2015 at 5:13 PM, Martin Bjork= lund <mbj@tail-f.com> wrote:
=

> >> - multiple create-subscription request in same NetConf ssh se= ssion
> >> using different channels. Basically multiplexing the same Net= Conf
> >> ssh session with multiple ssh channel.
> > --> This point I did not understand. Do you mean, that = there will be
> > multiple SSH sessions with single NETCONFS sessi= on ?
> > I guess your intention is that you want to subset each notificati= on,
> > and want to get those subsets in different SSH channel for load > > balancing ?
>
> Yes Rohit.

Currently, each SSH channel becomes a separate NETCONF session.=C2=A0 So this proposal would require a new binding for NETCONF over SSH, and a
concept of "channels" in the base NETCONF protocol.=C2=A0 I don&#= 39;t think
this is a good idea.


/martin



--
Ambika Prasad Tripat= hy
Cell @+91 9437547730/8553070866
skype:ambika_nethawk
--047d7bd6be0a11743b050f47d203-- From nobody Tue Feb 17 04:34: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 1A58A1A8858 for ; Tue, 17 Feb 2015 04:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E19rHLoBfIPG for ; Tue, 17 Feb 2015 04:34:00 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF44B1A1AF4 for ; Tue, 17 Feb 2015 04:34:00 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3407D8ED; Tue, 17 Feb 2015 13:33:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kUHoFWz3Qo_0; Tue, 17 Feb 2015 13:33:58 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 17 Feb 2015 13:33:58 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C97B20036; Tue, 17 Feb 2015 13:33:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xu8Yg9BmFki3; Tue, 17 Feb 2015 13:33:57 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 499F220031; Tue, 17 Feb 2015 13:33:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 551733231EE9; Tue, 17 Feb 2015 13:33:57 +0100 (CET) Date: Tue, 17 Feb 2015 13:33:57 +0100 From: Juergen Schoenwaelder To: Ambika Tripathy Message-ID: <20150217123357.GA24211@elstar.local> Mail-Followup-To: Ambika Tripathy , Martin Bjorklund , Rohit R Ranade , "netconf@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A671E3384@szxeml512-mbs.china.huawei.com> <3B675C3A8DF102408C754E30986E43CF10FB3AF3@xmb-aln-x08.cisco.com> <20150217.124314.1253557840502628376.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: Rohit R Ranade , "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 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, 17 Feb 2015 12:34:06 -0000 On Tue, Feb 17, 2015 at 05:57:04PM +0530, Ambika Tripathy wrote: > > That mean, one netconf session is only limited to only one subscription and > the subscription will end with session close. This is what the notification document says. > For multiple subscription request the same application needs to create > multiple netconf session. This follows from it. > Is not it mean, the NetConf is not utilization the complete capability of > underlying transport i.e. SSH. I think RFC 6242 says that an SSH channel maps 1:1 to a NETCONF session. RFC 6242 does not explicitely talk about using multiple SSH channels but it also does not forbit to use multiple SSH channels. So I guess this is currently up to implementations to sort out. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Feb 17 07:14: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 EB96E1A88F4 for ; Tue, 17 Feb 2015 07:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wh_9DYQosLfR for ; Tue, 17 Feb 2015 07:14:03 -0800 (PST) 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 1B3501A873A for ; Tue, 17 Feb 2015 07:14:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPJ74223; Tue, 17 Feb 2015 15:14:01 +0000 (GMT) Received: from SZXEML431-HUB.china.huawei.com (10.82.67.208) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Feb 2015 15:14:00 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.141]) by szxeml431-hub.china.huawei.com ([10.82.67.208]) with mapi id 14.03.0158.001; Tue, 17 Feb 2015 23:13:50 +0800 From: Rohit R Ranade To: Juergen Schoenwaelder , "Ambika Tripathy" Thread-Topic: [Netconf] Notification updation RFC 5277 Thread-Index: AdAdmGPAceznqgnXSje9O6PD47W4GwKspEggBix6hTAAAhGVgAAEnTcAAABOrgAAAoyFgAAC/EgAAAFgtoABgRO+gP//ruCA//9t0yCABtfRAP//c4wQgADYhYCAABWOAIAADD8AgAAB7ID//1BBsA== Date: Tue, 17 Feb 2015 15:13:49 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A671E33CE@szxeml512-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A671E3384@szxeml512-mbs.china.huawei.com> <3B675C3A8DF102408C754E30986E43CF10FB3AF3@xmb-aln-x08.cisco.com> <20150217.124314.1253557840502628376.mbj@tail-f.com> <20150217123357.GA24211@elstar.local> In-Reply-To: <20150217123357.GA24211@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.144.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 15:14:06 -0000 Hi, I feel there are two points that are being discussed now. a) Ease of use : Allowing a modification of subscription requests. b) Load-balancing of notifications. I think that multiplexing of SSH channels will only make it complex for NET= CONF to handle multiple channels. It will need to manage As to which notifications need to be sent on which channels.=20 It might handle load-balancing in a way but at the cost of complexity of SS= H and NETCONF channel handling. With Regards, Rohit -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: 17 February, 2015 18:04 To: Ambika Tripathy Cc: Martin Bjorklund; Rohit R Ranade; netconf@ietf.org Subject: Re: [Netconf] Notification updation RFC 5277 On Tue, Feb 17, 2015 at 05:57:04PM +0530, Ambika Tripathy wrote: >=20 > That mean, one netconf session is only limited to only one subscription a= nd > the subscription will end with session close. This is what the notification document says. > For multiple subscription request the same application needs to create > multiple netconf session. This follows from it. > Is not it mean, the NetConf is not utilization the complete capability of > underlying transport i.e. SSH. I think RFC 6242 says that an SSH channel maps 1:1 to a NETCONF session. RFC 6242 does not explicitely talk about using multiple SSH channels but it also does not forbit to use multiple SSH channels. So I guess this is currently up to implementations to sort out. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Feb 17 07:34: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 F40FE1A8A44 for ; Tue, 17 Feb 2015 07:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1a-SWwActY6 for ; Tue, 17 Feb 2015 07:34:14 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BD01A8A46 for ; Tue, 17 Feb 2015 07:34:12 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7275DAAB; Tue, 17 Feb 2015 16:34:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EPHXchBoPYHM; Tue, 17 Feb 2015 16:34:09 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 17 Feb 2015 16:34:10 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A305D20037; Tue, 17 Feb 2015 16:34:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id V3jlitUyIvHM; Tue, 17 Feb 2015 16:34:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0198D20031; Tue, 17 Feb 2015 16:34:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0E8813232051; Tue, 17 Feb 2015 16:34:09 +0100 (CET) Date: Tue, 17 Feb 2015 16:34:09 +0100 From: Juergen Schoenwaelder To: Rohit R Ranade Message-ID: <20150217153408.GB24550@elstar.local> Mail-Followup-To: Rohit R Ranade , Ambika Tripathy , Martin Bjorklund , "netconf@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A671E3384@szxeml512-mbs.china.huawei.com> <3B675C3A8DF102408C754E30986E43CF10FB3AF3@xmb-aln-x08.cisco.com> <20150217.124314.1253557840502628376.mbj@tail-f.com> <20150217123357.GA24211@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A671E33CE@szxeml512-mbs.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671E33CE@szxeml512-mbs.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Notification updation RFC 5277 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, 17 Feb 2015 15:34:17 -0000 On Tue, Feb 17, 2015 at 03:13:49PM +0000, Rohit R Ranade wrote: > Hi, > > I feel there are two points that are being discussed now. > a) Ease of use : Allowing a modification of subscription requests. > b) Load-balancing of notifications. > > I think that multiplexing of SSH channels will only make it complex for NETCONF to handle multiple channels. It will need to manage > As to which notifications need to be sent on which channels. > It might handle load-balancing in a way but at the cost of complexity of SSH and NETCONF channel handling. > I think you should forget about load balancing here since multiple SSH channels all run over a single TCP connection. The application needs to handle multiple channels, NETCONF has no issue since it defines only what happens inside a session / channel. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Feb 17 13:01: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 86B541A7005 for ; Tue, 17 Feb 2015 13:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dC2LN3Nc9mP5 for ; Tue, 17 Feb 2015 13:01:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869F51A8747 for ; Tue, 17 Feb 2015 13:01:06 -0800 (PST) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB538.namprd05.prod.outlook.com (10.141.73.24) with Microsoft SMTP Server (TLS) id 15.1.81.19; Tue, 17 Feb 2015 21:00:45 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.87.18; Tue, 17 Feb 2015 21:00:43 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) with mapi id 15.01.0087.013; Tue, 17 Feb 2015 21:00:43 +0000 From: Kent Watsen To: Andy Bierman , "netconf@ietf.org" Thread-Topic: [Netconf] 3 new related RESTCONF/anyxml Issues Thread-Index: AQHQSgtk8ZQTxZmwikidjfRcdpojvZz1AawA Date: Tue, 17 Feb 2015 21:00:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.10] authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(87936001)(83506001)(92566002)(66066001)(36756003)(77156002)(86362001)(99286002)(40100003)(2900100001)(2656002)(50986999)(2501002)(107886001)(2950100001)(46102003)(102836002)(106116001)(122556002)(62966003)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <145E2454390A0C4EADD0571F26B90486@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2015 21:00:43.2812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB538; X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] 3 new related RESTCONF/anyxml Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 21:01:13 -0000 >RESTCONF #17: terminal nodes as resources > >I just noticed that the term 'data resource' in sec. 1.3.4 does not >include leaf-list as a node that can be a data resource. >The draft is mostly silent about the processing of terminal nodes as >data resources (except patching a leaf). >Details and examples for leaf-list and anyxml should be added. > >Proposed solution: > > --> leaf-list as data resource rules TBD > --> anyxml edited as a whole. Nested data nodes in anyxml mare still > part of the anyxml resource, not a new sub-resource Agreed > RESTCONF #18: depth parameter and anyxml > >The depth parameter in 4.8.4 says each new child level increments >the depth level. The terminology mixes 'data node', 'resource', >and 'sub-resource'. > >Proposed solution: > > ---> for counting nest levels, sub-resources are counted, not data >nodes. > anyxml nodes cannot have sub-resources Agreed >RESTCONF #19: fields parameter and anyxml > >The fields parameter in 4.8.5 does not say if nested data nodes within >an anyxml object can be selected or not. > >Proposed solution: > > ---> for selecting nested data nodes, anyxml is treated as a terminal >node > so no sub-nodes within an instance can be selected with the >fields > parameter. Agreed K. From nobody Tue Feb 17 15:58:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFBB1A897C for ; Tue, 17 Feb 2015 15:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 S7GDQruJ4OBn for ; Tue, 17 Feb 2015 15:57:49 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CFF1A88D8 for ; Tue, 17 Feb 2015 15:57:49 -0800 (PST) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB393.namprd05.prod.outlook.com (10.141.75.24) with Microsoft SMTP Server (TLS) id 15.1.87.18; Tue, 17 Feb 2015 23:57:23 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.87.18; Tue, 17 Feb 2015 23:57:17 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) with mapi id 15.01.0087.013; Tue, 17 Feb 2015 23:57:17 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: disallow xmlns prefixes in RESTCONF? Thread-Index: AQHQRv/6joSDIlwH+0uYSmSM2pMgow== Date: Tue, 17 Feb 2015 23:57:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.10] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(87936001)(83506001)(2351001)(92566002)(19580395003)(66066001)(36756003)(77156002)(86362001)(99286002)(40100003)(2900100001)(2656002)(50986999)(229853001)(2501002)(110136001)(106116001)(46102003)(107886001)(102836002)(450100001)(122556002)(62966003)(54356999)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2015 23:57:16.8939 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB393; X-OriginatorOrg: juniper.net Archived-At: Subject: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 23:57:51 -0000 Just submitted RESTCONF issue #20 (https://github.com/netconf-wg/restconf/issues/20): NETCONF is too permissive. Rather than allow wild variations including: Maybe only allow default namespaces (e.g., no prefixes), so the above can only be encoded as: Thoughts? Thanks, Kent // looking for a fire-retardant... From nobody Tue Feb 17 16:06:12 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6BC1A9108 for ; Tue, 17 Feb 2015 16:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS2nNCeuQReD for ; Tue, 17 Feb 2015 16:06:10 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498421A9107 for ; Tue, 17 Feb 2015 16:06:09 -0800 (PST) Received: from BLUPR05CA0046.namprd05.prod.outlook.com (10.141.20.16) by BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) with Microsoft SMTP Server (TLS) id 15.1.81.19; Wed, 18 Feb 2015 00:05:50 +0000 Received: from BY2FFO11FD012.protection.gbl (2a01:111:f400:7c0c::155) by BLUPR05CA0046.outlook.office365.com (2a01:111:e400:855::16) with Microsoft SMTP Server (TLS) id 15.1.87.18 via Frontend Transport; Wed, 18 Feb 2015 00:05:50 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Wed, 18 Feb 2015 00:05:50 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 17 Feb 2015 16:05:49 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t1I05kW23724; Tue, 17 Feb 2015 16:05:46 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t1I05Vr0058743; Tue, 17 Feb 2015 19:05:32 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502180005.t1I05Vr0058743@idle.juniper.net> To: Kent Watsen In-Reply-To: Date: Tue, 17 Feb 2015 19:05:31 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(164054003)(48376002)(87936001)(106466001)(81156004)(1941001)(54356999)(50466002)(6806004)(50986999)(53416004)(69596002)(110136001)(76506005)(47776003)(2950100001)(558084003)(77096005)(105596002)(86362001)(92566002)(62966003)(450100001)(77156002)(46102003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB434; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:BLUPR05MB434; X-Forefront-PRVS: 04916EA04C X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2015 00:05:50.0407 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB434 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:06:11 -0000 Kent Watsen writes: >NETCONF is too permissive. Rather than allow wild variations including: This new encoding isn't XML and isn't standard. XML gives the encoder the flexibility to choose between alternative representations of identical data. There is no canonical form. Thanks, Phil From nobody Tue Feb 17 16:38:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108CC1A882E for ; Tue, 17 Feb 2015 16:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofP81GVLr_63 for ; Tue, 17 Feb 2015 16:38:40 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252F11A87AE for ; Tue, 17 Feb 2015 16:38:40 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB362.namprd05.prod.outlook.com (10.141.51.147) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 18 Feb 2015 00:38:22 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) with mapi id 15.01.0087.013; Wed, 18 Feb 2015 00:38:22 +0000 From: Kent Watsen To: Phil Shafer Thread-Topic: [Netconf] disallow xmlns prefixes in RESTCONF? Thread-Index: AQHQSw638Kbz7lk+xU+cVslkzUk0fJz1PHYA Date: Wed, 18 Feb 2015 00:38:22 +0000 Message-ID: References: <201502180005.t1I05Vr0058743@idle.juniper.net> In-Reply-To: <201502180005.t1I05Vr0058743@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.10] authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB362; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB362; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2950100001)(36756003)(106116001)(86362001)(76176999)(2656002)(77156002)(122556002)(62966003)(87936001)(2900100001)(66066001)(110136001)(102836002)(92566002)(558084003)(46102003)(99286002)(54356999)(83506001)(50986999)(450100001)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB362; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <4D891564F6388749BEBB1ADFA1A22652@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2015 00:38:22.3702 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB362 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:38:42 -0000 >This new encoding isn't XML and isn't standard. How so? >XML gives the >encoder the flexibility to choose between alternative representations >of identical data. There is no canonical form. True, and hence the "problem" K. From nobody Tue Feb 17 16:47: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 A42441A8893 for ; Tue, 17 Feb 2015 16:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6u7x7ND1jzV for ; Tue, 17 Feb 2015 16:47:55 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A010F1A8846 for ; Tue, 17 Feb 2015 16:47:54 -0800 (PST) Received: from BL2PR05CA0045.namprd05.prod.outlook.com (10.255.226.45) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 00:47:53 +0000 Received: from BY2FFO11FD028.protection.gbl (2a01:111:f400:7c0c::133) by BL2PR05CA0045.outlook.office365.com (2a01:111:e400:c04::45) with Microsoft SMTP Server (TLS) id 15.1.87.18 via Frontend Transport; Wed, 18 Feb 2015 00:47:52 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Wed, 18 Feb 2015 00:47:52 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 17 Feb 2015 16:47:50 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t1I0lnW42015; Tue, 17 Feb 2015 16:47:49 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t1I0lZDF059196; Tue, 17 Feb 2015 19:47:35 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502180047.t1I0lZDF059196@idle.juniper.net> To: Kent Watsen In-Reply-To: Date: Tue, 17 Feb 2015 19:47:35 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(110136001)(106466001)(86362001)(50466002)(47776003)(48376002)(105596002)(46102003)(92566002)(50986999)(53416004)(2950100001)(62966003)(76506005)(87936001)(54356999)(6806004)(77096005)(450100001)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:BLUPR05MB435; X-Forefront-PRVS: 04916EA04C X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2015 00:47:52.4719 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB435 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:47:56 -0000 Kent Watsen writes: >>This new encoding isn't XML and isn't standard. >How so? You are trying to make a subset of XML. Subsets by definition aren't the full thing. A subset of XML isn't XML. That means when you make an XML library call to emit XML, it will make XML that doesn't follow the rules of your subset. You need distinct custom encoding functions, which diminishes the value of following the standard. Thanks, Phil From nobody Tue Feb 17 16:52: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 B07A21A88F3 for ; Tue, 17 Feb 2015 16:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kBjTgGbPG7M for ; Tue, 17 Feb 2015 16:52:43 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7806B1A8846 for ; Tue, 17 Feb 2015 16:52:43 -0800 (PST) Received: by lbiw7 with SMTP id w7so7844915lbi.10 for ; Tue, 17 Feb 2015 16:52:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oBEvqmLcJwgCG0ygQiNVQgbTuBrp+uM/mf/9mlk9u5Y=; b=HEFvddEtQRkiYlylKJoxnnKhbDkv+orHbjjA/l0eCqJQGKv8/PyzWUfaBnVl/7Trx7 vJbD4J0Rwi5G6oLHpXYJG6U5VuMxb9tssEnc8klm87yt2tH1dDwi2rpHY0Z/c9eJ4Z2A G3stdho9Sgih7lH3ytbZugOCwWgNqZV6qnnQrB/S51YLuuMI4V4ld6qx4EnsQ1DOJss+ xXYWP3hh6+k9cf3wo2mEnHYKD/wt1qU8e7FE8rItGE6ynzPEkKpF4R00mQ4nO5kRl4Wp tOhrRPrRs3p+iwHOhZ0bVBW3bY44BbzaYt/+P+k6mBziKJQ9N2NOEEc52IzbyVkc7vWg 2maw== X-Gm-Message-State: ALoCoQl50YjOVXVl4VIIZpJdM1/gQIxLjTlblkdQKi6rmWuPRbFTlQo+0ltcdbzO7Ym/+wqtoHcc MIME-Version: 1.0 X-Received: by 10.112.164.101 with SMTP id yp5mr31224728lbb.82.1424220761954; Tue, 17 Feb 2015 16:52:41 -0800 (PST) Received: by 10.112.78.3 with HTTP; Tue, 17 Feb 2015 16:52:41 -0800 (PST) In-Reply-To: References: <201502180005.t1I05Vr0058743@idle.juniper.net> Date: Tue, 17 Feb 2015 16:52:41 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:52:45 -0000 On Tue, Feb 17, 2015 at 4:38 PM, Kent Watsen wrote: > > >>This new encoding isn't XML and isn't standard. > > How so? > By creating an ad-hoc subset of XML just for NETCONF. > >>XML gives the >>encoder the flexibility to choose between alternative representations >>of identical data. There is no canonical form. > > True, and hence the "problem" I agree with Phil that we cannot make prefixes invalid in NETCONF. I don't see the problem. Processing xmlns attributes is still required either way. > > > K. Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Feb 17 20:10: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 22CD61A8989 for ; Tue, 17 Feb 2015 20:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJgwKOHw-c0x for ; Tue, 17 Feb 2015 20:10:43 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB2E1A8987 for ; Tue, 17 Feb 2015 20:10:43 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB363.namprd05.prod.outlook.com (10.141.51.145) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 18 Feb 2015 04:10:41 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) with mapi id 15.01.0087.013; Wed, 18 Feb 2015 04:10:41 +0000 From: Kent Watsen To: Phil Shafer Thread-Topic: [Netconf] disallow xmlns prefixes in RESTCONF? Thread-Index: AQHQSw638Kbz7lk+xU+cVslkzUk0fJz1PHYAgABWZYD//+TvgA== Date: Wed, 18 Feb 2015 04:10:41 +0000 Message-ID: References: <201502180047.t1I0lZDF059196@idle.juniper.net> In-Reply-To: <201502180047.t1I0lZDF059196@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.10] authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB363; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB363; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(51704005)(479174004)(66066001)(86362001)(87936001)(106116001)(62966003)(99286002)(2950100001)(76176999)(83506001)(19580405001)(40100003)(450100001)(77156002)(19580395003)(2656002)(2900100001)(110136001)(92566002)(46102003)(122556002)(102836002)(50986999)(36756003)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB363; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2015 04:10:41.4575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB363 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 04:10:45 -0000 On 2/17/15, 7:47 PM, "Phil Shafer" wrote: >Kent Watsen writes: >>>This new encoding isn't XML and isn't standard. >>How so? > >You are trying to make a subset of XML. Subsets by definition >aren't the full thing. A subset of XML isn't XML. That means when >you make an XML library call to emit XML, it will make XML that >doesn't follow the rules of your subset. You need distinct custom >encoding functions, which diminishes the value of following the >standard. OK, good, at first I thought you were trying to say the example wasn't valid XML, as it most certainly is. As for correctness, I'm pretty sure it can be proven that any XML document can be converted to the form where all namespaces are declared locally to the element where they are used (for attributes, which do not inherit the default namespace, the prefix can also be set in the local element). These are just optional encoding strategies and this one seems to be best practice that happens to align nicely with the JSON-encoding strategy. Yes, it's a subset, so what? Is it any different than 6020 using a subset of XPath for leafref and instance-identifier statements? FWIW, I realize that this is a long shot, hence my fire-retardent quip at the start ;) Kent From nobody Tue Feb 17 23:45:52 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEC01A90EC for ; Tue, 17 Feb 2015 23:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-axYimFZ-Wy for ; Tue, 17 Feb 2015 23:45:46 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1B41A9105 for ; Tue, 17 Feb 2015 23:45:46 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 4CF8812801AA; Wed, 18 Feb 2015 08:45:45 +0100 (CET) Date: Wed, 18 Feb 2015 08:45:45 +0100 (CET) Message-Id: <20150218.084545.942091274043335672.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <201502180005.t1I05Vr0058743@idle.juniper.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 07:45:51 -0000 Andy Bierman wrote: > On Tue, Feb 17, 2015 at 4:38 PM, Kent Watsen wrote: > > > > > >>This new encoding isn't XML and isn't standard. > > > > How so? > > > > By creating an ad-hoc subset of XML just for NETCONF. > > > > >>XML gives the > >>encoder the flexibility to choose between alternative representations > >>of identical data. There is no canonical form. > > > > True, and hence the "problem" > > I agree with Phil that we cannot make prefixes invalid in NETCONF. > I don't see the problem. +1 Kent, you didn't describe what the perceived "problem" is, you just presented a solution... /martin From nobody Wed Feb 18 00:53:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6311A8722 for ; Wed, 18 Feb 2015 00:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9_RRvGXnxEV for ; Wed, 18 Feb 2015 00:53:18 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id EDBE51A914A for ; Wed, 18 Feb 2015 00:53:17 -0800 (PST) Received: from [10.148.226.151] (unknown [10.148.226.151]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F92212801AA; Wed, 18 Feb 2015 09:53:16 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_879D2FC5-6311-48BB-9C15-B51F4CD1A6A9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Jan Lindblad In-Reply-To: Date: Wed, 18 Feb 2015 09:51:43 +0100 Message-Id: References: <201502180047.t1I0lZDF059196@idle.juniper.net> To: Kent Watsen X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 08:53:19 -0000 --Apple-Mail=_879D2FC5-6311-48BB-9C15-B51F4CD1A6A9 Content-Type: multipart/alternative; boundary="Apple-Mail=_45343379-5B51-4DC4-8228-E5B92B10299A" --Apple-Mail=_45343379-5B51-4DC4-8228-E5B92B10299A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kent, > As for correctness, I'm pretty sure it can be proven that any XML = document > can be converted to the form where all namespaces are declared locally = to > the element where they are used (for attributes, which do not inherit = the > default namespace, the prefix can also be set in the local element). Not true. Counterexample: Best Regards, /jan --Apple-Mail=_45343379-5B51-4DC4-8228-E5B92B10299A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kent,

As = for correctness, I'm pretty sure it can be proven that any XML = document
can be converted to the form where all namespaces = are declared locally to
the element where they are used = (for attributes, which do not inherit the
default = namespace, the prefix can also be set in the local element).

Not true. = Counterexample:

   <y:foo xmlns=3D"x" = xmlns:y=3D"y" xmlns:z=3D=E2=80=9Cz=E2=80=9D y:attr=3D=E2=80=9C1=E2=80=9D = z:attr=3D=E2=80=9C2">
     <z:bar>
       <z:baz/>=
     </z:bar>
   </y:foo>

Best Regards,
/jan

= --Apple-Mail=_45343379-5B51-4DC4-8228-E5B92B10299A-- --Apple-Mail=_879D2FC5-6311-48BB-9C15-B51F4CD1A6A9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU5FKgAAoJEBSCnbqufIis7WcH/29mJyviR9FImQP3Oa8/mLWM 15VIaX1tXcvYOPhufSnNMgWohUL6iLqtIRAK5n6H38FfDy+mvVzSrv0D0dIGpDoa +DG8O+7h2/Iz7bqmrNfRZJVvOI5Po0WmBgHaE+cfNEG71XC7KkSatL2sDMi099/k oMxmoOdeEe0wpKmkEhLmftO4glIT4hQMTQ3YxIkrXOmjvvGzW+kswSt1u6n/189G JUgy++r0D1wak7UALLz3F1KUbNE7TeaGOhVxmvE1MYrlcrvz1nX57pIKsZGg4zQc 5ERC/X4DjFAkxQBO43B0egLT6hTR37bOTEnNXcTQEOwl8OtJQM052oxDkuRkaQ8= =6KC1 -----END PGP SIGNATURE----- --Apple-Mail=_879D2FC5-6311-48BB-9C15-B51F4CD1A6A9-- From nobody Wed Feb 18 06:55: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 00DE01A87D7 for ; Wed, 18 Feb 2015 06:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Y2g7MaeguBg for ; Wed, 18 Feb 2015 06:55:43 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5501A87A1 for ; Wed, 18 Feb 2015 06:55:43 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB361.namprd05.prod.outlook.com (10.141.51.148) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 18 Feb 2015 14:55:41 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) with mapi id 15.01.0087.013; Wed, 18 Feb 2015 14:55:41 +0000 From: Kent Watsen To: Jan Lindblad Thread-Topic: [Netconf] disallow xmlns prefixes in RESTCONF? Thread-Index: AQHQSw638Kbz7lk+xU+cVslkzUk0fJz1PHYAgABWZYD//+TvgIAAolWAgAAR3IA= Date: Wed, 18 Feb 2015 14:55:41 +0000 Message-ID: References: <201502180047.t1I0lZDF059196@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.11] authentication-results: tail-f.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB361; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB361; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(2656002)(62966003)(66066001)(99286002)(50986999)(19580405001)(87936001)(19580395003)(86362001)(40100003)(83506001)(2950100001)(16236675004)(122556002)(54356999)(77156002)(76176999)(46102003)(2900100001)(36756003)(93886004)(110136001)(102836002)(106116001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB361; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D10A1215972ECkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2015 14:55:41.1378 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB361 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:55:46 -0000 --_000_D10A1215972ECkwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Jan Lindblad > Date: Wednesday, February 18, 2015 at 3:51 AM To: Kent Watsen > Cc: Phil Shafer >, "netconf@ietf.= org" > Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? As for correctness, I'm pretty sure it can be proven that any XML document can be converted to the form where all namespaces are declared locally to the element where they are used (for attributes, which do not inherit the default namespace, the prefix can also be set in the local element). Not true. Counterexample: --_000_D10A1215972ECkwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Jan Lindblad <janl@tail-f.com>
Date: Wednesday, February 18, 2015 = at 3:51 AM
To: Kent Watsen <kwatsen@juniper.net>
Cc: Phil Shafer <phil@juniper.net>, "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] disallow xml= ns prefixes in RESTCONF?

As for correctness, I'm pretty sure it can be proven that a= ny XML document
can be converted to the form where all namespaces are declared locally to the element where they are used (for attributes, which do not inherit the default namespace, the prefix can also be set in the local element).

Not true. Counterexample:

   <y:foo xmlns=3D= "x" xmlns:y=3D"y" xmlns:z=3D“z” y:attr=3D&#= 8220;1” z:attr=3D“2">
  &nbs= p;  <z:bar>
  &nbs= p;    <z:baz/>
  &nbs= p;  </z:bar>
  &nbs= p;</y:foo>

 --_000_D10A1215972ECkwatsenjunipernet_-- From nobody Wed Feb 18 07:02:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08211A9141 for ; Wed, 18 Feb 2015 07:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3NNS73yQm-J for ; Wed, 18 Feb 2015 07:02:02 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E011A895A for ; Wed, 18 Feb 2015 07:02:01 -0800 (PST) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB377.namprd05.prod.outlook.com (10.141.51.20) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 15:01:59 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 15:01:57 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.10]) with mapi id 15.01.0087.013; Wed, 18 Feb 2015 15:01:56 +0000 From: Kent Watsen To: Jan Lindblad Thread-Topic: [Netconf] disallow xmlns prefixes in RESTCONF? Thread-Index: AQHQSw638Kbz7lk+xU+cVslkzUk0fJz1PHYAgABWZYD//+TvgIAAolWAgAATmwA= Date: Wed, 18 Feb 2015 15:01:56 +0000 Message-ID: References: <201502180047.t1I0lZDF059196@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.11] authentication-results: tail-f.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(87936001)(83506001)(92566002)(66066001)(77156002)(36756003)(86362001)(99286002)(40100003)(2900100001)(93886004)(2656002)(50986999)(110136001)(2950100001)(106116001)(46102003)(102836002)(122556002)(62966003)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <45E1B50A96796546AADF79D6F30973C8@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2015 15:01:56.4018 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB377; X-OriginatorOrg: juniper.net Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 15:02:04 -0000 [Sorry for the previous empty message - leave it to Outlook to have the "Send" button next to the button to convert a message to plain text] >> As for correctness, I'm pretty sure it can be proven that any XML >>document >> can be converted to the form where all namespaces are declared locally >>to >> the element where they are used (for attributes, which do not inherit >>the >> default namespace, the prefix can also be set in the local element). >> > Not true. Counterexample: > > > > > > Easy peasy: But I grant you that this is using prefixes (per my last comment above), contrary to the title, and it gets into the ugly, which is partially what I'm hoping to avoid with this consideration... Cheers, Kent From nobody Fri Feb 20 05:55:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030071A802E for ; Fri, 20 Feb 2015 05:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2tgCCMKqYFU for ; Fri, 20 Feb 2015 05:55:45 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADEC1A7D81 for ; Fri, 20 Feb 2015 05:55:44 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-db-54e73cde6e61 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 30.1D.24955.EDC37E45; Fri, 20 Feb 2015 14:55:43 +0100 (CET) Received: from [159.107.197.216] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.210.2; Fri, 20 Feb 2015 14:55:42 +0100 Message-ID: <54E73CDD.5020409@ericsson.com> Date: Fri, 20 Feb 2015 14:55:41 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "netconf@ietf.org" Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3Rve+zfMQg13PGC2mbrrN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO9HXzIWPOeo2HL4NWMD40W2LkYODgkBE4nmZVpdjJxAppjE hXvrgcJcHEICRxglpjdNYIRw1jJKbDp/ngWkildAW+Lt0lOMIDaLgKrEkoUNYHE2ASOJqf0Q NaICURKzzz9ghagXlDg58wlYXERAU6Jx1gewODNQ/ZXdP8HmCAuESPxf9I0dIm4hMXP+eUYI W15i+9s5zCC2kICGxMMLf1knMPLPQjJ2FpKWWUhaFjAyr2IULU4tTspNNzLWSy3KTC4uzs/T y0st2cQIDLWDW36r7mC8/MbxEKMAB6MSD6/B4mchQqyJZcWVuYcYpTlYlMR57YwPhQgJpCeW pGanphakFsUXleakFh9iZOLglGpgFHu0bflhnv5pSSJX95zfMEfG744CT885tacGOke8TnDp aqXO6QiW3npnsolY5lTHPLaSUv/i/HMf2I1XW2+f0PHCLI15/WzX+fsz6kL2Kzcdb7pUpch7 oKIv+uv1Pf7S15bXfPeqmJAT7Boho9c4oUBStFeE6+S0o8c5bgTO5Xvt4ZzUa8GmxFKckWio xVxUnAgAlciUxBYCAAA= Archived-At: Cc: Peter Labraaten Subject: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 20 Feb 2015 13:55:47 -0000 Hello, I assume that " hello" with the leading space is a perfectly OK value in Netconf/YANG for a string leaf. I also think that the " hello" string is not the same as the "hello" string without the space. However https://tools.ietf.org/html/rfc6241#section-6.2.5 part of the Netconf RFC says about filtering "Leading and trailing whitespace characters are ignored, but any whitespace characters within a block of text characters are not ignored or modified." IMHO this is an error for YANG string leafs. It is perfectly OK to convert an integer " 1" into "1" but converting the string " hello" into "hello" is changing its content. So there should be an errata stating that for string type content all white space content is considered during filtering. Agree? If you do not agree, how am I supposed to filter for " hello" instead of "hello"? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Sat Feb 21 17:15:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678E81A0191 for ; Sat, 21 Feb 2015 17:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_IMAGE_ONLY_32=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 Prx-u1rbqjUi for ; Sat, 21 Feb 2015 17:14:59 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e: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 48F881A016A for ; Sat, 21 Feb 2015 17:14:59 -0800 (PST) Received: by paceu11 with SMTP id eu11so17936600pac.7 for ; Sat, 21 Feb 2015 17:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=Ps351KUDA9hfpmsB4DMH6+86SfXrWBoM7CsPBDzlbDo=; b=smGbZncaoEAN/z97rdfbQEh4x/nWIUJDIp+hukzBwsb+QaxeZ9UsXG1WyXm2Tl1xg9 uDmbVO4P4gSQbNPBYQHyaqZis9xHCrPDouKrWbu47rCvNRl3g4waqvT7s2pMVgyVe1aB HhTM4QxaSlkYG4nUYfUVDKvGhVqzzSK6W7B6aeue6ZH3hUzo7oVE8tGjl8OXXtCN1G6z gYnXDpDv8lRZNVZiRJszZbbnXN0BP7GcOUOCZavaLPuj+WASYIFZVyDeUI4rdelsDotp XNI0jzcVtCfgte0g2gnO/FEzTc6Bwe6LM6WrjoiFkQ1pjSTmfdM2QuMFo9Ph/WRzZJVi 5b2A== X-Received: by 10.70.137.99 with SMTP id qh3mr8016736pdb.39.1424567698590; Sat, 21 Feb 2015 17:14:58 -0800 (PST) Received: from ?IPv6:2602:306:cf77:f4c0:4118:b4ac:555c:a255? ([2602:306:cf77:f4c0:4118:b4ac:555c:a255]) by mx.google.com with ESMTPSA id b5sm15523975pdj.88.2015.02.21.17.14.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Feb 2015 17:14:57 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_473CE843-804C-40B7-B465-B40885226974" Message-Id: Date: Sat, 21 Feb 2015 17:14:56 -0800 To: netconf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Netconf] Agenda for 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: Sun, 22 Feb 2015 01:15:01 -0000 --Apple-Mail=_473CE843-804C-40B7-B465-B40885226974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft agenda for IETF 92 has been posted. According to it, NETCONF = WG meets on. This is subject to change. 1300-1500 CDT Tuesday Afternoon Session I Gold OPS = netconf = Network Configuration Mahesh and Mehmet --Apple-Mail=_473CE843-804C-40B7-B465-B40885226974 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The draft agenda for IETF 92 has been posted. According to = it, NETCONF WG meets on. This is subject to change.

1300-1500 CDTTuesday Afternoon Session = I





GoldOPSnetconf3D""= Network = Configuration

Mahesh and Mehmet





= --Apple-Mail=_473CE843-804C-40B7-B465-B40885226974-- From nobody Sun Feb 22 03:12:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060561A1BD9 for ; Sun, 22 Feb 2015 03:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 Ooj3DsjAeVB4 for ; Sun, 22 Feb 2015 03:12:49 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951221A1BD2 for ; Sun, 22 Feb 2015 03:12:48 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.93.16; Sun, 22 Feb 2015 11:07:49 +0000 Message-ID: <00ca01d04e8f$8766de60$4001a8c0@gateway.2wire.net> From: t.petch To: Balazs Lengyel , References: <54E73CDD.5020409@ericsson.com> Date: Sun, 22 Feb 2015 10:59:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: AMSPR02CA0016.eurprd02.prod.outlook.com (10.242.225.144) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:DBXPR07MB061; X-Forefront-PRVS: 04953B1F22 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(51444003)(189002)(252514010)(51704005)(13464003)(76176999)(81686999)(62236002)(44716002)(1456003)(47776003)(15975445007)(23756003)(66066001)(50986999)(81816999)(77096005)(92566002)(101416001)(68736005)(77156002)(62966003)(64706001)(61296003)(46102003)(42186005)(84392001)(33646002)(50466002)(19580395003)(19580405001)(86362001)(122386002)(44736004)(50226001)(106356001)(40100003)(1556002)(105586002)(87976001)(14496001)(116806002)(97736003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2015 11:07:49.5938 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB061 Archived-At: Cc: Peter Labraaten Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 22 Feb 2015 11:12:51 -0000 ----- Original Message ----- From: "Balazs Lengyel" To: Cc: "Peter Labraaten" Sent: Friday, February 20, 2015 1:55 PM > Hello, > I assume that " hello" with the leading space is a perfectly OK value in > Netconf/YANG for a string leaf. I also think that the " hello" string is > not the same as the "hello" string without the space. > However https://tools.ietf.org/html/rfc6241#section-6.2.5 part of the > Netconf RFC says about filtering > > "Leading and trailing whitespace characters are ignored, but any > whitespace characters within a block of text characters are not > ignored or modified." > > IMHO this is an error for YANG string leafs. It is perfectly OK to > convert an integer " 1" into "1" but converting the string " hello" > into "hello" is changing its content. So there should be an errata > stating that for string type content all white space content is > considered during filtering. > > Agree? If you do not agree, how am I supposed to filter for " hello" > instead of "hello"? You can't! I think that the Netconf RFC is very clear. YANG does allow spaces to be significant or not, depending on the quoting (RFC6020 s6.1.3) but Netconf, as you point out, does not. Nor is this an erratum, which would imply that the RFC wrongly (or unclearly) states the consensus of the WG. The text you cite first appears in draft-ietf-netconf-prot-06 in April 2005, following an e-mail from Andy at http://www.ietf.org/mail-archive/web/netconf/current/msg00414.html The earlier text also came from Andy http://www.ietf.org/mail-archive/web/netconf/current/msg00004.html There was a lengthy discourse on subpath filtering between the two but that was about whether to have home-grown filtering, a subset of XPath or full XPath or some combination thereof. Tom Petch > regards Balazs > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Sun Feb 22 08:10: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 EA0221A1BDD for ; Sun, 22 Feb 2015 08:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QniXoil5GX6J for ; Sun, 22 Feb 2015 08:10:14 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926F71A1BDA for ; Sun, 22 Feb 2015 08:10:13 -0800 (PST) Received: by lbvp9 with SMTP id p9so14497949lbv.0 for ; Sun, 22 Feb 2015 08:10:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uFKAjdXWPjPPFCmXzR+emiTN2Joho59ZCiNq79Sr0Cs=; b=HXZnA/IC2AksMGATVcxH7sseoTr7NuE+e/lrVOiFi4kz+39QJjDgdzt6PCzoAbbGjl bHk5r39rtvBb7OUKulzDYj2Vvng3DVquKTzrRD2MmwpCBO7pI6bh/uC1100913D4z8QR yhQuKpFTYYEcubrgMsEI2jT6Jrfm1gOr6RiBwuI21X7y+wzfApQjGUODCjapASpH096S UV159Z1HKT9VxzqBz/fmWMxCurJSP/+9P8UH0QaXb8dFJvjBDvx5DoeO+UYGj4kG1BqW S5k7TpO/ncRKQ0iqyev1BXrkq9CIDxdWcpVyKPkX/DdO3cpFcbwJBBN1eqcroX7q2NsG jfpA== X-Gm-Message-State: ALoCoQk8w91OCNZa774Q2o/pHyxJ5GU+iCAofHWv6XSScOnxTuFb5+ln7Pz2HEkWIz6p4BkjLGAU MIME-Version: 1.0 X-Received: by 10.152.243.4 with SMTP id wu4mr6254737lac.33.1424621412028; Sun, 22 Feb 2015 08:10:12 -0800 (PST) Received: by 10.112.144.36 with HTTP; Sun, 22 Feb 2015 08:10:11 -0800 (PST) In-Reply-To: <54E73CDD.5020409@ericsson.com> References: <54E73CDD.5020409@ericsson.com> Date: Sun, 22 Feb 2015 08:10:11 -0800 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netconf@ietf.org" , Peter Labraaten Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 22 Feb 2015 16:10:16 -0000 On Fri, Feb 20, 2015 at 5:55 AM, Balazs Lengyel wrote: > Hello, > I assume that " hello" with the leading space is a perfectly OK value in > Netconf/YANG for a string leaf. I also think that the " hello" string is not > the same as the "hello" string without the space. > However https://tools.ietf.org/html/rfc6241#section-6.2.5 part of the > Netconf RFC says about filtering > > "Leading and trailing whitespace characters are ignored, but any > whitespace characters within a block of text characters are not > ignored or modified." > > IMHO this is an error for YANG string leafs. It is perfectly OK to convert > an integer " 1" into "1" but converting the string " hello" into "hello" is > changing its content. So there should be an errata stating that for string > type content all white space content is considered during filtering. > > Agree? If you do not agree, how am I supposed to filter for " hello" instead > of "hello"? I don't think our server actually trims whitespace. (Any server using content_match_test from yuma does the same thing). It compares the entire value. This text is probably left over from when the WG thought it was OK for the XML parser to trim whitespace. There was an incorrect assumption the following are equivalent some string some string > regards Balazs > Andy > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Feb 23 02:19: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 D562E1A044F for ; Mon, 23 Feb 2015 02:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdyQJztaKjmx for ; Mon, 23 Feb 2015 02:19:43 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCCE1A03C7 for ; Mon, 23 Feb 2015 02:19:42 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 521AF1CC0249; Mon, 23 Feb 2015 11:19:48 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer , Kent Watsen In-Reply-To: <201502180005.t1I05Vr0058743@idle.juniper.net> References: <201502180005.t1I05Vr0058743@idle.juniper.net> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 23 Feb 2015 11:19:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 10:19:45 -0000 Phil Shafer writes: > Kent Watsen writes: >>NETCONF is too permissive. Rather than allow wild variations including: > > This new encoding isn't XML and isn't standard. XML gives the > encoder the flexibility to choose between alternative representations > of identical data. There is no canonical form. Actually, there is one: http://www.w3.org/TR/xml-c14n2 However, it understandably doesn't go as far as Kent's proposal. I agree with the others that RESTCONF implementations supporting XML have to accept all legal namespace encodings. Lada > > Thanks, > Phil > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 23 05:21:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30A81A1ADF for ; Mon, 23 Feb 2015 05:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3XZ4QWvN5ow for ; Mon, 23 Feb 2015 05:21:19 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D91611A1ACC for ; Mon, 23 Feb 2015 05:21:18 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8C9511CC0249; Mon, 23 Feb 2015 14:21:24 +0100 (CET) From: Ladislav Lhotka To: Balazs Lengyel , "netconf\@ietf.org" In-Reply-To: <54E73CDD.5020409@ericsson.com> References: <54E73CDD.5020409@ericsson.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 23 Feb 2015 14:21:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Peter Labraaten Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 23 Feb 2015 13:21:20 -0000 Balazs Lengyel writes: > Hello, > I assume that " hello" with the leading space is a perfectly OK value in > Netconf/YANG for a string leaf. I also think that the " hello" string is > not the same as the "hello" string without the space. > However https://tools.ietf.org/html/rfc6241#section-6.2.5 part of the > Netconf RFC says about filtering > > "Leading and trailing whitespace characters are ignored, but any > whitespace characters within a block of text characters are not > ignored or modified." > > IMHO this is an error for YANG string leafs. It is perfectly OK to > convert an integer " 1" into "1" but converting the string " hello" > into "hello" is changing its content. So there should be an errata > stating that for string type content all white space content is > considered during filtering. > > Agree? If you do not agree, how am I supposed to filter for " hello" > instead of "hello"? I agree. It is perfectly legal (albeit hardly recommendable) to define the following enums in YANG, and they have to be regarded as distinct by a NETCONF server: enum "foo"; enum " foo"; Lada > regards Balazs > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 23 08:29: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 146A91A00D0 for ; Mon, 23 Feb 2015 08:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 916oaf5yYZSG for ; Mon, 23 Feb 2015 08:29:23 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE7D1A1AAA for ; Mon, 23 Feb 2015 08:29:22 -0800 (PST) Received: by labhz20 with SMTP id hz20so19505539lab.0 for ; Mon, 23 Feb 2015 08:29:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3pqWbQb9LK4Rz7/hb3GTe5bWPgP4xvF0YSdJ3MgE+LE=; b=UpO/fNUnKeDROzTzmmcl/Nk0tmcZfgAKN7mRJpIb8T9QZ6wLp9wNbAxx6wOnMFYIlb 3T76ExJe6JfoDh4bNg2weRks3R7P0RWXKZ/PEG1TEhcvhzgVylzHwXNILXEGJp6aCxF9 nqVLGZnO+eOUIv4CsjhoovoCV6GnrZjLnvaZEYmgtVdsjsb+Ah4nLgaaZ0iRWHNcO/fr nmE/BymsH4CzRgcz1ZY6+RY8985sN8BKyJv5NHws4/BcqleFjtW3J7fDRhX5wT6k0sLu nvtWh64XFvzd+FQUPhp9CBKOuAQOB98RNoKumTDMGuolbvBgpAPXCMP9zcAcIKc5J60R yxyQ== X-Gm-Message-State: ALoCoQk36JC3u4j3md4LCWFP4LIVMUDw6y9Ix0Ujzr0rp54mHftj49UcAH83KJhIZLGHSJQe9DIY MIME-Version: 1.0 X-Received: by 10.112.148.38 with SMTP id tp6mr5182829lbb.82.1424708961188; Mon, 23 Feb 2015 08:29:21 -0800 (PST) Received: by 10.112.144.36 with HTTP; Mon, 23 Feb 2015 08:29:21 -0800 (PST) In-Reply-To: References: <54E73CDD.5020409@ericsson.com> Date: Mon, 23 Feb 2015 08:29:21 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Peter Labraaten , "netconf@ietf.org" Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 23 Feb 2015 16:29:29 -0000 On Mon, Feb 23, 2015 at 5:21 AM, Ladislav Lhotka wrote: > Balazs Lengyel writes: > >> Hello, >> I assume that " hello" with the leading space is a perfectly OK value in >> Netconf/YANG for a string leaf. I also think that the " hello" string is >> not the same as the "hello" string without the space. >> However https://tools.ietf.org/html/rfc6241#section-6.2.5 part of the >> Netconf RFC says about filtering >> >> "Leading and trailing whitespace characters are ignored, but any >> whitespace characters within a block of text characters are not >> ignored or modified." >> >> IMHO this is an error for YANG string leafs. It is perfectly OK to >> convert an integer " 1" into "1" but converting the string " hello" >> into "hello" is changing its content. So there should be an errata >> stating that for string type content all white space content is >> considered during filtering. >> >> Agree? If you do not agree, how am I supposed to filter for " hello" >> instead of "hello"? > > I agree. It is perfectly legal (albeit hardly recommendable) to define > the following enums in YANG, and they have to be regarded as distinct by > a NETCONF server: > > enum "foo"; > enum " foo"; > This is not allowed, From 9.6.4: It takes as an argument a string which is the assigned name. The string MUST NOT be empty and MUST NOT have any leading or trailing whitespace characters. The use of Unicode control codes SHOULD be avoided. > Lada Andy > >> regards Balazs >> >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 Tel: +36-1-437-7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Feb 23 09:08:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14DD1A1B6E for ; Mon, 23 Feb 2015 09:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ErkRdT7_xBFb for ; Mon, 23 Feb 2015 09:08:48 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0137.outbound.protection.outlook.com [207.46.100.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F28E1A1AA2 for ; Mon, 23 Feb 2015 09:08:48 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB362.namprd05.prod.outlook.com (10.141.51.147) with Microsoft SMTP Server (TLS) id 15.1.93.16; Mon, 23 Feb 2015 17:08:46 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.145]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.145]) with mapi id 15.01.0093.004; Mon, 23 Feb 2015 17:08:46 +0000 From: Kent Watsen To: Ladislav Lhotka , Phil Shafer Thread-Topic: [Netconf] disallow xmlns prefixes in RESTCONF? Thread-Index: AQHQSw638Kbz7lk+xU+cVslkzUk0fJz+DlkAgAAedwA= Date: Mon, 23 Feb 2015 17:08:46 +0000 Message-ID: References: <201502180005.t1I05Vr0058743@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB362; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB362; x-forefront-prvs: 0496DF6962 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(2950100001)(102836002)(2900100001)(97736003)(558084003)(101416001)(1941001)(62966003)(68736005)(77156002)(92566002)(36756003)(105586002)(2656002)(106356001)(99286002)(83506001)(40100003)(66066001)(46102003)(122556002)(86362001)(106116001)(64706001)(76176999)(54356999)(50986999)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB362; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <9587F3B1E4F6804CB7B0FB96830E6280@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2015 17:08:46.3670 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB362 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] disallow xmlns prefixes in RESTCONF? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 17:08:50 -0000 >I agree with the others that RESTCONF implementations supporting XML >have to accept all legal namespace encodings. OK, it seems that no one feels like this is a good idea, so I closed the issue as dead. Thanks, Kent From nobody Mon Feb 23 10: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 285561A1E0E for ; Mon, 23 Feb 2015 10:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41t1rYvaMxic for ; Mon, 23 Feb 2015 10:55:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D59F1A1F02 for ; Mon, 23 Feb 2015 10:55:20 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:54ad:feb6:3ad3:9330] (unknown [IPv6:2a01:5e0:29:ffff:54ad:feb6:3ad3:9330]) by mail.nic.cz (Postfix) with ESMTPSA id 0E3F11439DA; Mon, 23 Feb 2015 19:55:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1424717718; bh=WiRj3t6ZFr/7f5lnmDWquONB/gYHmhMceie3uYXEN3w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eLsDq3R13B8Y8q4I2qZmcn4VLsJxZZYJ1nZHiHpblgweAI3r5T1V7ZRloNyokYK3D YcYJETf1pMYL54ngK5btTc1RpoSIrKSx20rd4N5kurC0fb3PyZHOYPbM7b7PFv8t19 lNGusJUpKy7u5nB7OsUlXewNj3ndmDU4NURX3KlU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 23 Feb 2015 19:55:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E73CDD.5020409@ericsson.com> To: Andy Bierman X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: Peter Labraaten , Netconf Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 23 Feb 2015 18:55:23 -0000 > On 23 Feb 2015, at 17:29, Andy Bierman wrote: >=20 > On Mon, Feb 23, 2015 at 5:21 AM, Ladislav Lhotka = wrote: >> Balazs Lengyel writes: >>=20 >>> Hello, >>> I assume that " hello" with the leading space is a perfectly OK = value in >>> Netconf/YANG for a string leaf. I also think that the " hello" = string is >>> not the same as the "hello" string without the space. >>> However https://tools.ietf.org/html/rfc6241#section-6.2.5 part of = the >>> Netconf RFC says about filtering >>>=20 >>> "Leading and trailing whitespace characters are ignored, but any >>> whitespace characters within a block of text characters are = not >>> ignored or modified." >>>=20 >>> IMHO this is an error for YANG string leafs. It is perfectly OK to >>> convert an integer " 1" into "1" but converting the string " hello" >>> into "hello" is changing its content. So there should be an errata >>> stating that for string type content all white space content is >>> considered during filtering. >>>=20 >>> Agree? If you do not agree, how am I supposed to filter for " hello" >>> instead of "hello"? >>=20 >> I agree. It is perfectly legal (albeit hardly recommendable) to = define >> the following enums in YANG, and they have to be regarded as distinct = by >> a NETCONF server: >>=20 >> enum "foo"; >> enum " foo"; >>=20 >=20 > This is not allowed, =46rom 9.6.4: >=20 > It takes as an argument a string which is the assigned name. The > string MUST NOT be empty and MUST NOT have any leading or trailing > whitespace characters. The use of Unicode control codes SHOULD be > avoided. OK, sorry, my fault. But still, e.g. list keys =E2=80=9Cfoo=E2=80=9D and = =E2=80=9C foo=E2=80=9D must be considered different. Trimming whitespace = in XML *elements* breaks all XML tools. Lada >=20 >> Lada >=20 > Andy >=20 >>=20 >>> regards Balazs >>>=20 >>>=20 >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> ECN: 831 7320 Tel: +36-1-437-7320 >>> Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >>>=20 >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 23 11:42:59 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A939C1A6EDB for ; Mon, 23 Feb 2015 11:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD9aRisGZZpA for ; Mon, 23 Feb 2015 11:42:57 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4CC1A3BA6 for ; Mon, 23 Feb 2015 11:42:56 -0800 (PST) Received: from localhost (host-90-237-135-209.mobileonline.telia.com [90.237.135.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 36732128048E; Mon, 23 Feb 2015 20:42:55 +0100 (CET) Date: Mon, 23 Feb 2015 20:42:54 +0100 (CET) Message-Id: <20150223.204254.464201352091987038.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org, peter.labraaten@ericsson.com Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 23 Feb 2015 19:42:58 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjMgRmVi IDIwMTUsIGF0IDE3OjI5LCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gT24gTW9uLCBGZWIgMjMsIDIwMTUgYXQgNToyMSBBTSwgTGFkaXNsYXYgTGhv dGthIDxsaG90a2FAbmljLmN6Pg0KPiA+IHdyb3RlOg0KPiA+PiBCYWxhenMgTGVuZ3llbCA8YmFs YXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPiB3cml0ZXM6DQo+ID4+IA0KPiA+Pj4gSGVsbG8sDQo+ ID4+PiBJIGFzc3VtZSB0aGF0ICIgaGVsbG8iIHdpdGggdGhlIGxlYWRpbmcgc3BhY2UgaXMgYSBw ZXJmZWN0bHkgT0sgdmFsdWUNCj4gPj4+IGluDQo+ID4+PiBOZXRjb25mL1lBTkcgZm9yIGEgc3Ry aW5nIGxlYWYuIEkgYWxzbyB0aGluayB0aGF0IHRoZSAiIGhlbGxvIiBzdHJpbmcNCj4gPj4+IGlz DQo+ID4+PiBub3QgdGhlIHNhbWUgYXMgdGhlICJoZWxsbyIgc3RyaW5nIHdpdGhvdXQgdGhlIHNw YWNlLg0KPiA+Pj4gSG93ZXZlciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI0MSNz ZWN0aW9uLTYuMi41IHBhcnQgb2YgdGhlDQo+ID4+PiBOZXRjb25mIFJGQyBzYXlzIGFib3V0IGZp bHRlcmluZw0KPiA+Pj4gDQo+ID4+PiAiTGVhZGluZyBhbmQgdHJhaWxpbmcgd2hpdGVzcGFjZSBj aGFyYWN0ZXJzIGFyZSBpZ25vcmVkLCBidXQgYW55DQo+ID4+PiAgICAgICB3aGl0ZXNwYWNlIGNo YXJhY3RlcnMgd2l0aGluIGEgYmxvY2sgb2YgdGV4dCBjaGFyYWN0ZXJzIGFyZSBub3QNCj4gPj4+ ICAgICAgIGlnbm9yZWQgb3IgbW9kaWZpZWQuIg0KPiA+Pj4gDQo+ID4+PiBJTUhPIHRoaXMgaXMg YW4gZXJyb3IgZm9yIFlBTkcgc3RyaW5nIGxlYWZzLiBJdCBpcyBwZXJmZWN0bHkgT0sgdG8NCj4g Pj4+IGNvbnZlcnQgYW4gaW50ZWdlciAiICAxIiBpbnRvICIxIiBidXQgY29udmVydGluZyB0aGUg c3RyaW5nICIgaGVsbG8iDQo+ID4+PiBpbnRvICJoZWxsbyIgaXMgY2hhbmdpbmcgaXRzIGNvbnRl bnQuIFNvIHRoZXJlIHNob3VsZCBiZSBhbiBlcnJhdGENCj4gPj4+IHN0YXRpbmcgdGhhdCBmb3Ig c3RyaW5nIHR5cGUgY29udGVudCBhbGwgd2hpdGUgc3BhY2UgY29udGVudCBpcw0KPiA+Pj4gY29u c2lkZXJlZCBkdXJpbmcgZmlsdGVyaW5nLg0KPiA+Pj4gDQo+ID4+PiBBZ3JlZT8gSWYgeW91IGRv IG5vdCBhZ3JlZSwgaG93IGFtIEkgc3VwcG9zZWQgdG8gZmlsdGVyIGZvciAiIGhlbGxvIg0KPiA+ Pj4gaW5zdGVhZCBvZiAiaGVsbG8iPw0KPiA+PiANCj4gPj4gSSBhZ3JlZS4gSXQgaXMgcGVyZmVj dGx5IGxlZ2FsIChhbGJlaXQgaGFyZGx5IHJlY29tbWVuZGFibGUpIHRvIGRlZmluZQ0KPiA+PiB0 aGUgZm9sbG93aW5nIGVudW1zIGluIFlBTkcsIGFuZCB0aGV5IGhhdmUgdG8gYmUgcmVnYXJkZWQg YXMgZGlzdGluY3QNCj4gPj4gYnkNCj4gPj4gYSBORVRDT05GIHNlcnZlcjoNCj4gPj4gDQo+ID4+ IGVudW0gImZvbyI7DQo+ID4+IGVudW0gIiBmb28iOw0KPiA+PiANCj4gPiANCj4gPiBUaGlzIGlz IG5vdCBhbGxvd2VkLCAgRnJvbSA5LjYuNDoNCj4gPiANCj4gPiAgIEl0IHRha2VzIGFzIGFuIGFy Z3VtZW50IGEgc3RyaW5nIHdoaWNoIGlzIHRoZSBhc3NpZ25lZCBuYW1lLiAgVGhlDQo+ID4gICBz dHJpbmcgTVVTVCBOT1QgYmUgZW1wdHkgYW5kIE1VU1QgTk9UIGhhdmUgYW55IGxlYWRpbmcgb3Ig dHJhaWxpbmcNCj4gPiAgIHdoaXRlc3BhY2UgY2hhcmFjdGVycy4gIFRoZSB1c2Ugb2YgVW5pY29k ZSBjb250cm9sIGNvZGVzIFNIT1VMRCBiZQ0KPiA+ICAgYXZvaWRlZC4NCj4gDQo+IE9LLCBzb3Jy eSwgbXkgZmF1bHQuIEJ1dCBzdGlsbCwgZS5nLiBsaXN0IGtleXMg4oCcZm9v4oCdIGFuZCDigJwg Zm9v4oCdIG11c3QNCj4gYmUgY29uc2lkZXJlZCBkaWZmZXJlbnQuDQoNClllcywgdGhleSBhcmUg YWJzb2x1dGVseSBkaWZmZXJlbnQuICBCdXQgeW91IGNhbm5vdCB1c2Ugc3VidHJlZQ0KZmlsdGVy aW5nIHRvIGdldCBqdXN0IG9uZSBvZiB0aGVtLiAgKFlvdSBjYW4gZ2V0IGJvdGgsIGFuZCB0aGVu IGFwcGx5DQpjbGllbnQtc2lkZSBsb2dpYyB0byBzaW5nbGUgb3V0IHRoZSBvbmUgeW91IGFjdHVh bGx5IHdlcmUgaW50ZXJlc3RlZA0KaW4pLg0KDQo+IFRyaW1taW5nIHdoaXRlc3BhY2UgaW4gWE1M ICplbGVtZW50cyogYnJlYWtzDQo+IGFsbCBYTUwgdG9vbHMuDQoNCk5vdCB0cnVlLiAgV2hpdGVz cGFjZXMgYXJlIHByZXNlcnZlZCBpbiBYTUwsIHllcywgYnV0IHRoYXQganVzdCBtZWFucw0KdGhh dCBnZW5lcmljIHRvb2xzIHdpbGwgbm90IGRvIGFueSB0cmltbWluZy4gIEFueSBjb21wbGlhbnQg c3VidHJlZQ0KZmlsdGVyaW5nIGltcGxlbWVudGF0aW9uIHdpbGwgdGh1cyBoYXZlIHRvIGRvIHRo ZSB0cmltbWluZyBhZnRlciBYTUwNCnBhcnNpbmcuDQoNCg0KL21hcnRpbg0K From nobody Mon Feb 23 12:16:12 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD93F1A0469 for ; Mon, 23 Feb 2015 12:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h57nVFSws_m7 for ; Mon, 23 Feb 2015 12:16:09 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549A11A6EFB for ; Mon, 23 Feb 2015 12:16:09 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:54ad:feb6:3ad3:9330] (unknown [IPv6:2a01:5e0:29:ffff:54ad:feb6:3ad3:9330]) by mail.nic.cz (Postfix) with ESMTPSA id E5BFA1439DA; Mon, 23 Feb 2015 21:16:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1424722568; bh=rE0Mbj2vaq85+qTv3emtY8pdM90jnbIwcuTyXNJ0gbM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Bx8df4hbb+bAd+Sf20xUHIGMjPQ2E6VWQPId3BDYXQcOGdxgTbY1yDJTAdt7A4YuD l0kznvZV9K5KBliLdSFrL7S9hOmtMdU+t2JQRh0YoeVLJighGfEVaIDL8ltUV5R3S6 05lTkKQEJDtvwkiYhsteKJ9eHDQ47JM4d3XfEf6A= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150223.204254.464201352091987038.mbj@tail-f.com> Date: Mon, 23 Feb 2015 21:16:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150223.204254.464201352091987038.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , Peter Labraaten Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 23 Feb 2015 20:16:10 -0000 > On 23 Feb 2015, at 20:42, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 23 Feb 2015, at 17:29, Andy Bierman wrote: >>>=20 >>> On Mon, Feb 23, 2015 at 5:21 AM, Ladislav Lhotka >>> wrote: >>>> Balazs Lengyel writes: >>>>=20 >>>>> Hello, >>>>> I assume that " hello" with the leading space is a perfectly OK = value >>>>> in >>>>> Netconf/YANG for a string leaf. I also think that the " hello" = string >>>>> is >>>>> not the same as the "hello" string without the space. >>>>> However https://tools.ietf.org/html/rfc6241#section-6.2.5 part of = the >>>>> Netconf RFC says about filtering >>>>>=20 >>>>> "Leading and trailing whitespace characters are ignored, but any >>>>> whitespace characters within a block of text characters are = not >>>>> ignored or modified." >>>>>=20 >>>>> IMHO this is an error for YANG string leafs. It is perfectly OK to >>>>> convert an integer " 1" into "1" but converting the string " = hello" >>>>> into "hello" is changing its content. So there should be an errata >>>>> stating that for string type content all white space content is >>>>> considered during filtering. >>>>>=20 >>>>> Agree? If you do not agree, how am I supposed to filter for " = hello" >>>>> instead of "hello"? >>>>=20 >>>> I agree. It is perfectly legal (albeit hardly recommendable) to = define >>>> the following enums in YANG, and they have to be regarded as = distinct >>>> by >>>> a NETCONF server: >>>>=20 >>>> enum "foo"; >>>> enum " foo"; >>>>=20 >>>=20 >>> This is not allowed, =46rom 9.6.4: >>>=20 >>> It takes as an argument a string which is the assigned name. The >>> string MUST NOT be empty and MUST NOT have any leading or trailing >>> whitespace characters. The use of Unicode control codes SHOULD be >>> avoided. >>=20 >> OK, sorry, my fault. But still, e.g. list keys =E2=80=9Cfoo=E2=80=9D = and =E2=80=9C foo=E2=80=9D must >> be considered different. >=20 > Yes, they are absolutely different. But you cannot use subtree > filtering to get just one of them. (You can get both, and then apply > client-side logic to single out the one you actually were interested > in). This is not how I read the text that Balazs cited: it says that leading = and trailing whitespace is ignored, and I understand it is ignored in = content match nodes. Therefore, the list entry with =E2=80=9C foo=E2=80=9D= key must be inaccessible, which is exactly what Balazs concluded. >=20 >> Trimming whitespace in XML *elements* breaks >> all XML tools. >=20 > Not true. Whitespaces are preserved in XML, yes, but that just means > that generic tools will not do any trimming. Any compliant subtree > filtering implementation will thus have to do the trimming after XML > parsing. Yes, but it means a complication, e.g. for converting subtree filters to = XPath, also because this whitespace trimming is not the same as the = effect of the normalize-space function. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 23 13:33:31 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 0DDAF1A3BA6 for ; Mon, 23 Feb 2015 13:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVUB0mzeaN2Y for ; Mon, 23 Feb 2015 13:33:28 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF911A6F28 for ; Mon, 23 Feb 2015 13:33:26 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.1.93.16; Mon, 23 Feb 2015 21:10:11 +0000 Message-ID: <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <20150223.204254.464201352091987038.mbj@tail-f.com> Date: Mon, 23 Feb 2015 21:07:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: AM3PR03CA018.eurprd03.prod.outlook.com (10.141.191.146) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:AMSPR07MB052; X-Forefront-PRVS: 0496DF6962 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(189002)(24454002)(13464003)(199003)(44716002)(92566002)(575784001)(86362001)(50466002)(116806002)(106356001)(101416001)(93886004)(62236002)(64706001)(47776003)(40100003)(97736003)(23676002)(68736005)(122386002)(77096005)(1456003)(15975445007)(84392001)(14496001)(105586002)(81686999)(66066001)(76176999)(33646002)(81816999)(50986999)(1556002)(87976001)(61296003)(19580405001)(44736004)(77156002)(50226001)(42186005)(19580395003)(62966003)(46102003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2015 21:10:11.6891 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB052 Archived-At: Cc: Netconf , Peter Labraaten Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 23 Feb 2015 21:33:30 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "Martin Björklund" Cc: "Netconf" ; "Peter Labraaten" Sent: Monday, February 23, 2015 8:16 PM > > > On 23 Feb 2015, at 20:42, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 23 Feb 2015, at 17:29, Andy Bierman wrote: > >>> > >>> On Mon, Feb 23, 2015 at 5:21 AM, Ladislav Lhotka > >>> wrote: > >>>> Balazs Lengyel writes: > >>>> > >>>>> Hello, > >>>>> I assume that " hello" with the leading space is a perfectly OK value > >>>>> in > >>>>> Netconf/YANG for a string leaf. I also think that the " hello" string > >>>>> is > >>>>> not the same as the "hello" string without the space. > >>>>> However https://tools.ietf.org/html/rfc6241#section-6.2.5 part of the > >>>>> Netconf RFC says about filtering > >>>>> > >>>>> "Leading and trailing whitespace characters are ignored, but any > >>>>> whitespace characters within a block of text characters are not > >>>>> ignored or modified." > >>>>> > >>>>> IMHO this is an error for YANG string leafs. It is perfectly OK to > >>>>> convert an integer " 1" into "1" but converting the string " hello" > >>>>> into "hello" is changing its content. So there should be an errata > >>>>> stating that for string type content all white space content is > >>>>> considered during filtering. > >>>>> > >>>>> Agree? If you do not agree, how am I supposed to filter for " hello" > >>>>> instead of "hello"? > >>>> > >>>> I agree. It is perfectly legal (albeit hardly recommendable) to define > >>>> the following enums in YANG, and they have to be regarded as distinct > >>>> by > >>>> a NETCONF server: > >>>> > >>>> enum "foo"; > >>>> enum " foo"; > >>>> > >>> > >>> This is not allowed, From 9.6.4: > >>> > >>> It takes as an argument a string which is the assigned name. The > >>> string MUST NOT be empty and MUST NOT have any leading or trailing > >>> whitespace characters. The use of Unicode control codes SHOULD be > >>> avoided. > >> > >> OK, sorry, my fault. But still, e.g. list keys “foo” and “ foo” must > >> be considered different. > > > > Yes, they are absolutely different. But you cannot use subtree > > filtering to get just one of them. (You can get both, and then apply > > client-side logic to single out the one you actually were interested > > in). > > This is not how I read the text that Balazs cited: it says that leading and trailing whitespace is ignored, and I understand it is ignored in content match nodes. Therefore, the list entry with “ foo” key must be inaccessible, which is exactly what Balazs concluded. Lada I agree. My reading of the text is that stripping the spaces applies to the content match node and that no such normalisation is performed on the data base element ("the leaf node element content"). Tom Petch > > > > >> Trimming whitespace in XML *elements* breaks > >> all XML tools. > > > > Not true. Whitespaces are preserved in XML, yes, but that just means > > that generic tools will not do any trimming. Any compliant subtree > > filtering implementation will thus have to do the trimming after XML > > parsing. > > Yes, but it means a complication, e.g. for converting subtree filters to XPath, also because this whitespace trimming is not the same as the effect of the normalize-space function. > > Lada > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Feb 23 13:51:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1F71A6F2B for ; Mon, 23 Feb 2015 13:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4s4S8lkkKYz for ; Mon, 23 Feb 2015 13:51:29 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C30A1A6F28 for ; Mon, 23 Feb 2015 13:51:29 -0800 (PST) Received: by labgd6 with SMTP id gd6so21715806lab.7 for ; Mon, 23 Feb 2015 13:51:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nQuO5DlTlw1N1lPb/2BwWzwjZu/PcNb/DbiBy/IQ5vU=; b=WtJ3IAXn+SQne71HA+O3zdL+XRttOAzbgfhgncsYOxJZfSTdRGDJ5+B2l/VpTlrBKQ qfstuczh0qfe5RIRCLq+PJrVmKYJo3J5N7DeXRt7gXRMtHs/j3Fog452Sxv98kGRZJZh B+OEw10QqO6sApPMdSuPHnOt6HZz4NAlncd8XIzeQ9uQNzhs+Nq8xTvuJujqN4HsUuNi XgpfAM78+iKtmt8IBgnEiP7MeJEGiP8irEbE2NAUNc6CM1sExm5ou1LzRgWL6c9gnWl7 eA6oIiw59DmM/A3H/SCf3/ZXJqKMs5sasHQr8r2iBUZrii/ncQ7Mu3x7ffSeOp0jfSTD QBLg== X-Gm-Message-State: ALoCoQmF0PHIepCuLYKmzKaHkbrssvseLp58pJzztOg5INSUJnyb/zrLAKW9Pkgap9NDBaIM7e0X MIME-Version: 1.0 X-Received: by 10.152.206.7 with SMTP id lk7mr1042357lac.37.1424728287838; Mon, 23 Feb 2015 13:51:27 -0800 (PST) Received: by 10.112.144.36 with HTTP; Mon, 23 Feb 2015 13:51:27 -0800 (PST) In-Reply-To: <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net> References: <20150223.204254.464201352091987038.mbj@tail-f.com> <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net> Date: Mon, 23 Feb 2015 13:51:27 -0800 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Peter Labraaten , Netconf Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 23 Feb 2015 21:51:31 -0000 On Mon, Feb 23, 2015 at 1:07 PM, t.petch wrote: > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "Martin Bj=C3=B6rklund" > Cc: "Netconf" ; "Peter Labraaten" > > Sent: Monday, February 23, 2015 8:16 PM >> >> > On 23 Feb 2015, at 20:42, Martin Bjorklund wrote: >> > >> > Ladislav Lhotka wrote: >> >> >> >>> On 23 Feb 2015, at 17:29, Andy Bierman wrote: >> >>> >> >>> On Mon, Feb 23, 2015 at 5:21 AM, Ladislav Lhotka >> >>> wrote: >> >>>> Balazs Lengyel writes: >> >>>> >> >>>>> Hello, >> >>>>> I assume that " hello" with the leading space is a perfectly OK > value >> >>>>> in >> >>>>> Netconf/YANG for a string leaf. I also think that the " hello" > string >> >>>>> is >> >>>>> not the same as the "hello" string without the space. >> >>>>> However https://tools.ietf.org/html/rfc6241#section-6.2.5 part > of the >> >>>>> Netconf RFC says about filtering >> >>>>> >> >>>>> "Leading and trailing whitespace characters are ignored, but any >> >>>>> whitespace characters within a block of text characters are > not >> >>>>> ignored or modified." >> >>>>> >> >>>>> IMHO this is an error for YANG string leafs. It is perfectly OK > to >> >>>>> convert an integer " 1" into "1" but converting the string " > hello" >> >>>>> into "hello" is changing its content. So there should be an > errata >> >>>>> stating that for string type content all white space content is >> >>>>> considered during filtering. >> >>>>> >> >>>>> Agree? If you do not agree, how am I supposed to filter for " > hello" >> >>>>> instead of "hello"? >> >>>> >> >>>> I agree. It is perfectly legal (albeit hardly recommendable) to > define >> >>>> the following enums in YANG, and they have to be regarded as > distinct >> >>>> by >> >>>> a NETCONF server: >> >>>> >> >>>> enum "foo"; >> >>>> enum " foo"; >> >>>> >> >>> >> >>> This is not allowed, From 9.6.4: >> >>> >> >>> It takes as an argument a string which is the assigned name. The > >> >>> string MUST NOT be empty and MUST NOT have any leading or > trailing >> >>> whitespace characters. The use of Unicode control codes SHOULD > be >> >>> avoided. >> >> >> >> OK, sorry, my fault. But still, e.g. list keys =E2=80=9Cfoo=E2=80=9D = and =E2=80=9C foo=E2=80=9D > must >> >> be considered different. >> > >> > Yes, they are absolutely different. But you cannot use subtree >> > filtering to get just one of them. (You can get both, and then > apply >> > client-side logic to single out the one you actually were interested >> > in). >> >> This is not how I read the text that Balazs cited: it says that > leading and trailing whitespace is ignored, and I understand it is > ignored in content match nodes. Therefore, the list entry with =E2=80=9C = foo=E2=80=9D > key must be inaccessible, which is exactly what Balazs concluded. > > Lada > > I agree. My reading of the text is that stripping the spaces applies to > the content match node and that no such normalisation is performed on > the data base element ("the leaf node element content"). > I think the issue Balazs raised is questioning why the server would alter the filter match expression. Why is this a feature? The client can create string leafs with leading and trailing whitespace, but not filter them with a content match node. > Tom Petch > Andy > > > > > > >> >> > >> >> Trimming whitespace in XML *elements* breaks >> >> all XML tools. >> > >> > Not true. Whitespaces are preserved in XML, yes, but that just > means >> > that generic tools will not do any trimming. Any compliant subtree >> > filtering implementation will thus have to do the trimming after XML >> > parsing. >> >> Yes, but it means a complication, e.g. for converting subtree filters > to XPath, also because this whitespace trimming is not the same as the > effect of the normalize-space function. >> >> Lada >> >> > >> > >> > /martin >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Feb 23 14:32:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162471A1A17 for ; Mon, 23 Feb 2015 14:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 yQOvyXkQ_kEq for ; Mon, 23 Feb 2015 14:32:50 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7556F1A0199 for ; Mon, 23 Feb 2015 14:32:30 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.93.16; Mon, 23 Feb 2015 22:32:07 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.145]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.145]) with mapi id 15.01.0093.004; Mon, 23 Feb 2015 22:32:08 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: zerotouch issues and fixes Thread-Index: AQHQT7iOdPe2gMCB50i3hPM2i00zrw== Date: Mon, 23 Feb 2015 22:32:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0496DF6962 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(76104003)(199003)(189002)(122556002)(40100003)(2351001)(107886001)(97736003)(86362001)(105586002)(68736005)(106356001)(102836002)(66066001)(87936001)(2656002)(64706001)(2900100001)(92566002)(561944003)(2501003)(106116001)(83506001)(54356999)(101416001)(99286002)(50986999)(46102003)(450100001)(62966003)(77156002)(36756003)(110136001)(229853001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1DF2D180620D784D9D1705EEBDF83A51@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2015 22:32:07.9823 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: [Netconf] zerotouch issues and fixes 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, 23 Feb 2015 22:32:52 -0000 Now that the call-home and server-model drafts have no more planned updates before entering Last Call, I'm ready to focus on the zerotouch draft again. The good news is that I've been thinking about some issues with the current draft and already have a proposal for how to fix them. The issues I'm thinking about are: 1) Loss of privacy as NMS admins need to interact with 3rd-party signing servers in order to get their Configlets signed. 2) Complexity in how 3rd-party signing server would be able to know who owns which devices, the burden of its role. 3) Loss of flexibility as a Configlet has to encode the device identifiers for the devices allowed to load it. The proposal to fix the above issues is to replace the concept of a 3rd-party Signing Authority with 1) NMSs can sign their own configurations with a Vendor-certified key and 2) Devices use a Vendor-provided =B3voucher= =B2 to authenticate NMSs. Stepping through this in detail, we have the following artifacts: NMS Certificate: * the first time NMS wants to enroll in Vendor's ZeroTouch program: * NMS generates a private key * NMS generates a certificate signing request (CSR) * NMS sends to Vendor its CSR * Vendor signs the CSR, filling in an "Owner ID" value * Vendor signs the CSR with Vendor private key * Vendor sends to NMS the resulting NMS Certificate Device-Owner Voucher: * at any time, Vendor can generate a Voucher that: * encodes an "Owner ID" (see NMS Certificate above) * encodes one or more device identifiers (e.g., serial-number) * encodes an expiration time (e.g. months, years, forever) * signed by Vendor private key Configuration: * when NMS ready to stage ZeroTouch configuration: * NMS generates configuration * NMS signs configuration with private key * NMS places onto Configuration Server all of the following: 1) signed Configuration 2) Device-Owner Voucher 3) NMS Certificate With this setup, the device's boot up procedure is roughly: * download the 3 artifacts from Configuration Server * process the Device-Owner Voucher: * verify that it was signed by Vendor private key * verify that its device-identifier is listed * extract the encoded Owner ID * process the NMS Certificate: * verify that it was signed by Vendor private key * verify that the Owner ID is same as extracted from Voucher * extract NMS public key * process the signed Configuration * verify that it was signed by the NMS private key * commit configuration into running datastore Please assume everything else in zerotouch-01 draft would remain the same. Note how this solution fixes all the above listed issues: 1) NMS admins now signed their own configurations, 2) Vendors now only need to provide a Voucher, 3) Configurations no longer has to encode which devices their for. As a design consideration, note that all the zerotouch proposals emphasize the use of static artifacts over protocol. This is so the artifacts can optionally be loaded from alternate sources (i.e. USB drive, over an L2 protocol, over a non-IP protocol, etc.). So, what do you think? - I'd like to get some feedback before posting a -02 draft! Thanks, Kent From nobody Mon Feb 23 16:27: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 A87151A036F for ; Mon, 23 Feb 2015 16:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8btziD_kntFd for ; Mon, 23 Feb 2015 16:27:16 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F201A00B6 for ; Mon, 23 Feb 2015 16:27:16 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so40251753obc.1 for ; Mon, 23 Feb 2015 16:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=04uKvH4gmblNTOS1ra7SFTJ3FdPZ8fcLFSkqFEZRH8o=; b=P1L33Zx4ofqpo/skkRj+/MxLRQwSNr3wfaSfc8JIvywHoGHxaKsXngpYks2TEAJmoA 5NOh0Ck/xIeycJbZlabr00+ZT9lgSGMph17Cus/BAi/xFmWrmYf1m9fSuLJatddPN1gg amICML9cg5jpRYzNxVnMZbo+CXDPfHw0avszG9bLtjeEKnXYa0R5FtPiboVntPaBPqS/ STBzSBz4XyK98wCmHF/wkxwSQdZlWkLPn/tHj/Hw5zJLZcUpc7QFA4IkFi4h+uTQ7sm4 SPnIu7/DAv23UfbMprAhTu8j7xgrbwzPYYvkomTBmeVCloSKamECl4NhAcQgG0h03y3J BalQ== X-Received: by 10.202.186.85 with SMTP id k82mr8771280oif.69.1424737635205; Mon, 23 Feb 2015 16:27:15 -0800 (PST) MIME-Version: 1.0 From: Mahesh Jethanandani Date: Tue, 24 Feb 2015 00:27:13 +0000 Message-ID: To: Netconf Content-Type: multipart/mixed; boundary=001a113cdebaa5194c050fca9403 Archived-At: Subject: [Netconf] Draft Agenda for 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: Tue, 24 Feb 2015 00:27:17 -0000 --001a113cdebaa5194c050fca9403 Content-Type: multipart/alternative; boundary=001a113cdebaa51947050fca9401 --001a113cdebaa51947050fca9401 Content-Type: text/plain; charset=UTF-8 Attached is the draft agenda for NETCONF WG in IETF 92. Please let the chairs know if you have any comments about the agenda. Thanks. Mahesh and Mehmet. --001a113cdebaa51947050fca9401 Content-Type: text/html; charset=UTF-8
Attached is the draft agenda for NETCONF WG in IETF 92. Please let the chairs know if you have any comments about the agenda.

Thanks.

Mahesh and Mehmet.
--001a113cdebaa51947050fca9401-- --001a113cdebaa5194c050fca9403 Content-Type: text/plain; charset=US-ASCII; name="agenda-ietf-92.txt" Content-Disposition: attachment; filename="agenda-ietf-92.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: 14bb8fab194350a83f91 77u/QWdlbmRhIGZvciB0aGUgTkVUQ09ORiBXRyBTZXNzaW9uIGluIElFVEYgOTINCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQrCoA0KSUVURiA5MiwgRGFsbGFz LCBNYXJjaCAyMy0yNywgMjAxNQ0KVFVFU0RBWSwgTWFyY2ggMjQsIDIwMTUNCjEzMDAtMTUwMCBH b2xkIC0gVHVlc2RheSBBZnRlcm5vb24gU2Vzc2lvbiBJDQpSb29tOiBHb2xkDQrCoA0KwqDCoCBX RyBDaGFpcnM6DQrCoMKgIE1laG1ldCBFcnN1ZSA8bWVobWV0LmVyc3VlIGF0IG5va2lhIGRvdCBj b20+DQogICBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pIGF0IGdtYWlsIGRvdCBj b20+DQrCoA0KwqDCoCBTY3JpYmVzIChJRiBub192b2x1bnRlZXJzIFRIRU4gd2FpdF9mb3JldmVy KQ0KwqDCoCBBZ2VuZGEgYmFzaGluZyAoMiBtaW51dGVzKQ0KwqDCoCBXRyBzdGF0dXMgcmV2aWV3 ICg1IG1pbnV0ZXMpDQrCoA0KwqDCoCBDaGFydGVyZWQgaXRlbXM6DQrCoA0KICAgICAgMS4gUkVT VENPTkYgUHJvdG9jb2wgLSBBLiBCaWVybWFuICgxNSBtaW4uKQ0KICAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mDQogICAgICAgIA0K ICAgICAgMi4gWUFORyBQYXRjaCBNZWRpYSBUeXBlIC0gQS4gQmllcm1hbiAoNSBtaW4uKQ0KICAg ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmct cGF0Y2gNCg0KICAgICAgMy4gWUFORyBNb2R1bGUgTGlicmFyeSAtIEEuIEJpZXJtYW4gKDEwIG1p bi4pDQogICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbmV0Y29uZi9kcmFmdC1pZXRm LW5ldGNvbmYteWFuZy1saWJyYXJ5Lw0KDQogICAgICA0LiBORVRDT05GIENhbGwgSG9tZSAtIEsu IFdhdHNlbiAoMTAgbWluLikNCiAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUNCg0KICAgICAgNS4gTkVUQ09ORiBTZXJ2ZXIgQ29u ZmlndXJhdGlvbiBNb2RlbCAtIEsuIFdhdHNlbiAoNSBtaW4uKQ0KICAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXNlcnZlci1tb2RlbA0KDQogICAg ICA2LiBaZXJvIFRvdWNoIFByb3Zpc2lvbmluZyBmb3IgTkVUQ09ORiBDYWxsIEhvbWUgKFplcm9U b3VjaCkgLSBLLiBXYXRzZW4gKDIwIG1pbi4pDQogICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoDQoNCiAgICAgIDcuIFJFU1RDT05G IENvbGxlY3Rpb24gUmVzb3VyY2UgLSBBLiBCaWVybWFuICgxMCBtaW4uKQ0KICAgICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25m LWNvbGxlY3Rpb24vDQoNCsKgwqAgTm9uLUNoYXJ0ZXJlZCBpdGVtczoNCsKgDQrCoMKgwqDCoMKg IDEuIEkyUlMgcmVxdWlyZW1lbnRzIG9uIE5FVENPTkYgLSBJMlJTIGNoYWlycyAoMTUgbWluLikN Cg0KwqDCoMKgwqDCoCAyLiBBIE5FVENPTkYgRXh0ZW5zaW9uIGZvciBEYXRhIEZyYWdtZW50YXRp b24gLSBHLiBaaGVuZyAoMTAgbWluLikNCsKgwqDCoMKgwqDCoMKgwqAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMQ0KDQogICAgICAz LiBSZXF1aXJlbWVudHMgZm9yIFN1YnNjcmlwdGlvbiB0byBZQU5HIERhdGFzdG9yZXMgLSBFcmlj IFZvaXQgKDEwIG1pbi4pDQrCoMKgwqDCoMKgwqDCoMKgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC12b2l0LWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMtMDANCsKgDQrCoMKgwqDC oMKgIDQuIFN1YnNjcmliaW5nIHRvIGRhdGFzdG9yZSBwdXNoIHVwZGF0ZXMgLSBBLiBDbGVtbSAo MTAgbWluLikNCsKgwqDCoMKgwqDCoMKgwqAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LW5ldG1vZC1jbGVtbS1kYXRhc3RvcmUtcHVzaC0wMA0KwqANCsKgDQrCoMKgIE9wZW4gbWlr ZToNCsKgDQrCoMKgIEFPQg0KwqANCg== --001a113cdebaa5194c050fca9403-- From nobody Tue Feb 24 01:39:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C056C1A874A for ; Tue, 24 Feb 2015 01:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 G2HXxRaoSZiU for ; Tue, 24 Feb 2015 01:39:49 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEECE1A8743 for ; Tue, 24 Feb 2015 01:39:48 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-6b-54ec46e263a6 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 81.94.04231.2E64CE45; Tue, 24 Feb 2015 10:39:46 +0100 (CET) Received: from [159.107.197.114] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.210.2; Tue, 24 Feb 2015 10:39:46 +0100 Message-ID: <54EC46E1.7020502@ericsson.com> Date: Tue, 24 Feb 2015 10:39:45 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: References: <20150223.204254.464201352091987038.mbj@tail-f.com> <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RveR25sQg99zLCymbrrN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDk7HAu2VVc8mDGfsYFxe0gXIyeHhICJxPbJq9kgbDGJC/fW A9lcHEICRxglHhzcyAySEBJYyygxt90NxOYV0JZY9G4zC4jNIqAqMbnhOpjNJmAkMbX/PJgt KhAlMfv8A1aIekGJkzOfgMVFgBZ8PP8QbKawQJLEnf+djBDL/jBJXL8yHSzBKRAo0XFuJiOI zSygIdE6Zy47hC0v0bx1NtRBGhIPL/xlncAoMAvJjllIWmYhaVnAyLyKUbQ4tbg4N93IWC+1 KDO5uDg/Ty8vtWQTIzAED275rbuDcfVrx0OMAhyMSjy8BYpvQoRYE8uKK3MPMUpzsCiJ89oZ HwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKixWo7jaZ3vt7R5OT9jnLRkpm+0tGRO+3Ii bar1VkWvW8m3b28SZ6tdnvm85cIB9WeeYofWbVs6leVqoK6A87p5iZFmD+1c76244iJ+LKpL +QBj8ItbX9VWnv8twOf96LWhp0e3ysyPK/x9di28e1YrWVBKa1L4nvcWdz/d2rh7c+rNiISy nPdKLMUZiYZazEXFiQCKDv5dIgIAAA== Archived-At: Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC? 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, 24 Feb 2015 09:39:51 -0000 Hello,
Although this might not be 100% standard compliant, I wrote the following internal guideline in Ericsson:
- When Netconf was designed they tried to make it data model agnostic as there was no accepted data modeling language at the time. Thus it would handle string attributes the same way as integer or binary attributes. While separating layers (protocol versus data model) is generally a good idea, this level of "data model agnostic" treatment is taking it too far, it is a mistake. 
- Comparing values does not and should not mean the same thing for strings and integers,
while the string "    aa  " and "aa" are different
the numbers  "   +1" and "1" are not.
- RFC6241 clearly states that whitespace has to be considered part of a string

Our responsibility is not just to follow the standard, but to be intuitive.  Trimming whitespace from a string is not intuitive, I would rather call it surprising.

Also if we would blindly follow RFC6241:
"Leading and trailing whitespace characters are ignored, but any whitespace characters within a block of text characters are not ignored or modified."
would mean that you would never ever get a content match for  the string "  aa" as ignoring  the whitespace in the content match input means, the content match input is first converted to "aa" and that is what we try to match, which will never be equal to "  aa". 

regards Balazs

On 2015-02-23 22:51, Andy Bierman wrote:
On Mon, Feb 23, 2015 at 1:07 PM, t.petch <ietfc@btconnect.com> wrote:

----- Original Message -----
From: "Ladislav Lhotka" <lhotka@nic.cz>
To: "Martin Björklund" <mbj@tail-f.com>
Cc: "Netconf" <netconf@ietf.org>; "Peter Labraaten"
<peter.labraaten@ericsson.com>
Sent: Monday, February 23, 2015 8:16 PM


          

            
On 23 Feb 2015, at 20:42, Martin Bjorklund <mbj@tail-f.com> wrote:

Ladislav Lhotka <lhotka@nic.cz> wrote:


            

              

              

                
On 23 Feb 2015, at 17:29, Andy Bierman <andy@yumaworks.com> wrote:

On Mon, Feb 23, 2015 at 5:21 AM, Ladislav Lhotka <lhotka@nic.cz>
wrote:


                

                  
Balazs Lengyel <balazs.lengyel@ericsson.com> writes:



                  

                    
Hello,
I assume that " hello" with the leading space is a perfectly OK


                  

                

              

            

          

        

        
value


        

          

            

              

                

                  

                    
in
Netconf/YANG for a string leaf. I also think that the " hello"


                  

                

              

            

          

        

        
string


        

          

            

              

                

                  

                    
is
not the same as the "hello" string without the space.
However https://tools.ietf.org/html/rfc6241#section-6.2.5 part


                  

                

              

            

          

        

        
of the


        

          

            

              

                

                  

                    
Netconf RFC says about filtering

"Leading and trailing whitespace characters are ignored, but any
     whitespace characters within a block of text characters are


                  

                

              

            

          

        

        
not


        

          

            

              

                

                  

                    
     ignored or modified."

IMHO this is an error for YANG string leafs. It is perfectly OK


                  

                

              

            

          

        

        
to


        

          

            

              

                

                  

                    
convert an integer "  1" into "1" but converting the string "


                  

                

              

            

          

        

        
hello"


        

          

            

              

                

                  

                    
into "hello" is changing its content. So there should be an


                  

                

              

            

          

        

        
errata


        

          

            

              

                

                  

                    
stating that for string type content all white space content is
considered during filtering.

Agree? If you do not agree, how am I supposed to filter for "


                  

                

              

            

          

        

        
hello"


        

          

            

              

                

                  

                    
instead of "hello"?


                  

                  
I agree. It is perfectly legal (albeit hardly recommendable) to


                

              

            

          

        

        
define


        

          

            

              

                

                  
the following enums in YANG, and they have to be regarded as


                

              

            

          

        

        
distinct


        

          

            

              

                

                  
by
a NETCONF server:

enum "foo";
enum " foo";



                

                
This is not allowed,  From 9.6.4:

 It takes as an argument a string which is the assigned name.  The


              

            

          

        

        

        

          

            

              

                
 string MUST NOT be empty and MUST NOT have any leading or


              

            

          

        

        
trailing


        

          

            

              

                
 whitespace characters.  The use of Unicode control codes SHOULD


              

            

          

        

        
be


        

          

            

              

                
 avoided.


              

              
OK, sorry, my fault. But still, e.g. list keys “foo” and “ foo”


            

          

        

        
must


        

          

            

              
be considered different.


            

            
Yes, they are absolutely different.  But you cannot use subtree
filtering to get just one of them.  (You can get both, and then


          

        

        
apply


        

          

            
client-side logic to single out the one you actually were interested
in).


          

          
This is not how I read the text that Balazs cited: it says that


        

        
leading and trailing whitespace is ignored, and I understand it is
ignored in content match nodes. Therefore, the list entry with “ foo”
key must be inaccessible, which is exactly what Balazs concluded.

Lada

I agree.  My reading of the text is that stripping the spaces applies to
the content match node and that no such normalisation is performed on
the data base element ("the leaf  node element content").



      

      
I think the issue Balazs raised is questioning why the server would alter
the filter match expression.  Why is this a feature?  The client can create
string leafs with leading and trailing whitespace, but not filter them
with a content match node.



      

        
Tom Petch



      

      
Andy



      

        







        

          

          

            

            

              
Trimming whitespace in XML *elements* breaks
all XML tools.


            

            
Not true.  Whitespaces are preserved in XML, yes, but that just


          

        

        
means


        

          

            
that generic tools will not do any trimming.  Any compliant subtree
filtering implementation will thus have to do the trimming after XML
parsing.


          

          
Yes, but it means a complication, e.g. for converting subtree filters


        

        
to XPath, also because this whitespace trimming is not the same as the
effect of the normalize-space function.


        

          
Lada



          

            

/martin


          

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




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



        

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


      

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


    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Tue Feb 24 01:55:33 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7B31A6F34 for ; Tue, 24 Feb 2015 01:55:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.26
X-Spam-Level: 
X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 m2kPYw7DmQ-x for ; Tue, 24 Feb 2015 01:55:28 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A121A8778 for ; Tue, 24 Feb 2015 01:55:12 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 08829733; Tue, 24 Feb 2015 10:55:11 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fg2Why2RXDHU; Tue, 24 Feb 2015 10:55:02 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Feb 2015 10:55:09 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E64F20031; Tue, 24 Feb 2015 10:55:09 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MdwVTDiSSG3b; Tue, 24 Feb 2015 10:55:07 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 307D820036; Tue, 24 Feb 2015 10:55:06 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 54B073236401; Tue, 24 Feb 2015 10:55:06 +0100 (CET)
Date: Tue, 24 Feb 2015 10:55:06 +0100
From: Juergen Schoenwaelder 
To: Balazs Lengyel 
Message-ID: <20150224095506.GA49832@elstar.local>
Mail-Followup-To: Balazs Lengyel , netconf@ietf.org
References:    <20150223.204254.464201352091987038.mbj@tail-f.com>  <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net>  <54EC46E1.7020502@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <54EC46E1.7020502@ericsson.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC?
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, 24 Feb 2015 09:55:31 -0000

Hi,

please note that RFC 6020 takes care of defining canonical
representations for most data types. RFC 6991 follows this practice
and does the same for the common typedefs. Hence, the representation
of a positive integer you can rely on is 1 and not +1.

/js

On Tue, Feb 24, 2015 at 10:39:45AM +0100, Balazs Lengyel wrote:
>    Hello,
>    Although this might not be 100% standard compliant, I wrote the following
>    internal guideline in Ericsson:
>    - When Netconf was designed they tried to make it data model agnostic as
>    there was no accepted data modeling language at the time. Thus it would
>    handle string attributes the same way as integer or binary attributes.
>    While separating layers (protocol versus data model) is generally a good
>    idea, this level of "data model agnostic" treatment is taking it too far,
>    it is a mistake.
>    - Comparing values does not and should not mean the same thing for strings
>    and integers,
>    while the string "    aa  " and "aa" are different
>    the numbers  "   +1" and "1" are not.
>    - RFC6241 clearly states that whitespace has to be considered part of a
>    string
> 
>    Our responsibility is not just to follow the standard, but to be
>    intuitive.  Trimming whitespace from a string is not intuitive, I would
>    rather call it surprising.
> 
>    Also if we would blindly follow RFC6241:
>    "Leading and trailing whitespace characters are ignored, but any
>    whitespace characters within a block of text characters are not ignored or
>    modified."
>    would mean that you would never ever get a content match for  the string
>    "  aa" as ignoring  the whitespace in the content match input means, the
>    content match input is first converted to "aa" and that is what we try to
>    match, which will never be equal to "  aa".
> 
>    regards Balazs
> 
>    On 2015-02-23 22:51, Andy Bierman wrote:
> 
>  On Mon, Feb 23, 2015 at 1:07 PM, t.petch [1] wrote:
> 
>  ----- Original Message -----
>  From: "Ladislav Lhotka" [2]
>  To: "Martin Bj�rklund" [3]
>  Cc: "Netconf" [4]; "Peter Labraaten"
>  [5]
>  Sent: Monday, February 23, 2015 8:16 PM
> 
> 
>  On 23 Feb 2015, at 20:42, Martin Bjorklund [6] wrote:
> 
>  Ladislav Lhotka [7] wrote:
> 
> 
>  On 23 Feb 2015, at 17:29, Andy Bierman [8] wrote:
> 
>  On Mon, Feb 23, 2015 at 5:21 AM, Ladislav Lhotka [9]
>  wrote:
> 
>  Balazs Lengyel [10] writes:
> 
> 
>  Hello,
>  I assume that " hello" with the leading space is a perfectly OK
> 
>  value
> 
>  in
>  Netconf/YANG for a string leaf. I also think that the " hello"
> 
>  string
> 
>  is
>  not the same as the "hello" string without the space.
>  However [11]https://tools.ietf.org/html/rfc6241#section-6.2.5 part
> 
>  of the
> 
>  Netconf RFC says about filtering
> 
>  "Leading and trailing whitespace characters are ignored, but any
>       whitespace characters within a block of text characters are
> 
>  not
> 
>       ignored or modified."
> 
>  IMHO this is an error for YANG string leafs. It is perfectly OK
> 
>  to
> 
>  convert an integer "  1" into "1" but converting the string "
> 
>  hello"
> 
>  into "hello" is changing its content. So there should be an
> 
>  errata
> 
>  stating that for string type content all white space content is
>  considered during filtering.
> 
>  Agree? If you do not agree, how am I supposed to filter for "
> 
>  hello"
> 
>  instead of "hello"?
> 
>  I agree. It is perfectly legal (albeit hardly recommendable) to
> 
>  define
> 
>  the following enums in YANG, and they have to be regarded as
> 
>  distinct
> 
>  by
>  a NETCONF server:
> 
>  enum "foo";
>  enum " foo";
> 
> 
>  This is not allowed,  From 9.6.4:
> 
>   It takes as an argument a string which is the assigned name.  The
> 
> 
>   string MUST NOT be empty and MUST NOT have any leading or
> 
>  trailing
> 
>   whitespace characters.  The use of Unicode control codes SHOULD
> 
>  be
> 
>   avoided.
> 
>  OK, sorry, my fault. But still, e.g. list keys "foo" and " foo"
> 
>  must
> 
>  be considered different.
> 
>  Yes, they are absolutely different.  But you cannot use subtree
>  filtering to get just one of them.  (You can get both, and then
> 
>  apply
> 
>  client-side logic to single out the one you actually were interested
>  in).
> 
>  This is not how I read the text that Balazs cited: it says that
> 
>  leading and trailing whitespace is ignored, and I understand it is
>  ignored in content match nodes. Therefore, the list entry with " foo"
>  key must be inaccessible, which is exactly what Balazs concluded.
> 
>  Lada
> 
>  I agree.  My reading of the text is that stripping the spaces applies to
>  the content match node and that no such normalisation is performed on
>  the data base element ("the leaf  node element content").
> 
> 
>  I think the issue Balazs raised is questioning why the server would alter
>  the filter match expression.  Why is this a feature?  The client can create
>  string leafs with leading and trailing whitespace, but not filter them
>  with a content match node.
> 
> 
>  Tom Petch
> 
> 
>  Andy
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  Trimming whitespace in XML *elements* breaks
>  all XML tools.
> 
>  Not true.  Whitespaces are preserved in XML, yes, but that just
> 
>  means
> 
>  that generic tools will not do any trimming.  Any compliant subtree
>  filtering implementation will thus have to do the trimming after XML
>  parsing.
> 
>  Yes, but it means a complication, e.g. for converting subtree filters
> 
>  to XPath, also because this whitespace trimming is not the same as the
>  effect of the normalize-space function.
> 
>  Lada
> 
> 
> 
>  /martin
> 
>  --
>  Ladislav Lhotka, CZ.NIC Labs
>  PGP Key ID: E74E8C0C
> 
> 
> 
> 
>  _______________________________________________
>  Netconf mailing list
>  [12]Netconf@ietf.org
>  [13]https://www.ietf.org/mailman/listinfo/netconf
> 
> 
>  _______________________________________________
>  Netconf mailing list
>  [14]Netconf@ietf.org
>  [15]https://www.ietf.org/mailman/listinfo/netconf
> 
>  _______________________________________________
>  Netconf mailing list
>  [16]Netconf@ietf.org
>  [17]https://www.ietf.org/mailman/listinfo/netconf
> 
>  --
>  Balazs Lengyel                       Ericsson Hungary Ltd.
>  Senior Specialist
>  ECN: 831 7320                        Tel: +36-1-437-7320
>  Mobile: +36-70-330-7909              email: [18]Balazs.Lengyel@ericsson.com
> 
> References
> 
>    Visible links
>    1. mailto:ietfc@btconnect.com
>    2. mailto:lhotka@nic.cz
>    3. mailto:mbj@tail-f.com
>    4. mailto:netconf@ietf.org
>    5. mailto:peter.labraaten@ericsson.com
>    6. mailto:mbj@tail-f.com
>    7. mailto:lhotka@nic.cz
>    8. mailto:andy@yumaworks.com
>    9. mailto:lhotka@nic.cz
>   10. mailto:balazs.lengyel@ericsson.com
>   11. https://tools.ietf.org/html/rfc6241#section-6.2.5
>   12. mailto:Netconf@ietf.org
>   13. https://www.ietf.org/mailman/listinfo/netconf
>   14. mailto:Netconf@ietf.org
>   15. https://www.ietf.org/mailman/listinfo/netconf
>   16. mailto:Netconf@ietf.org
>   17. https://www.ietf.org/mailman/listinfo/netconf
>   18. mailto:Balazs.Lengyel@ericsson.com

> _______________________________________________
> 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 Tue Feb 24 02:04: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 80D831A8759 for ; Tue, 24 Feb 2015 02:04:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.061
X-Spam-Level: 
X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrOy3T7Q987d for ; Tue, 24 Feb 2015 02:04:38 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017131A8727 for ; Tue, 24 Feb 2015 02:04:38 -0800 (PST)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 808B2140A50; Tue, 24 Feb 2015 11:04:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1424772276; bh=890BWvFWBFvIvl2RS36E1dQWzwUgZKvvXEjNxANzhnU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WXC9gm0tiO5lTBPkyY80sBkG4PC+FK/ZxD8dMtFdaPts04zjfa5TaAE1Ug6bTQ9mJ Qalj3VlpcsB1HP6V1igM8hO+vMexQ072v/SWZQVsIJn+dNwc8s+DKFhZrrSRCuGrSa 9Jkj128wwfPMSXtjCYYbTNGs+8iqXZAnXNHQxP1I=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ladislav Lhotka 
In-Reply-To: <54EC46E1.7020502@ericsson.com>
Date: Tue, 24 Feb 2015 11:04:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <679A7F27-0BE6-4DCA-BBA4-3378043BD3CC@nic.cz>
References:    <20150223.204254.464201352091987038.mbj@tail-f.com>  <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net>  <54EC46E1.7020502@ericsson.com>
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.2070.6)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC?
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, 24 Feb 2015 10:04:40 -0000

> On 24 Feb 2015, at 10:39, Balazs Lengyel  =
wrote:
>=20
> Hello,
> Although this might not be 100% standard compliant, I wrote the =
following internal guideline in Ericsson:
> - When Netconf was designed they tried to make it data model agnostic =
as there was no accepted data modeling language at the time. Thus it =
would handle string attributes the same way as integer or binary =
attributes. While separating layers (protocol versus data model) is =
generally a good idea, this level of "data model agnostic" treatment is =
taking it too far, it is a mistake. =20
> - Comparing values does not and should not mean the same thing for =
strings and integers,=20
> while the string "    aa  " and "aa" are different=20
> the numbers  "   +1" and "1" are not.

Actually, RFC 6020 says nothing about the handling of whitespace in =
numeric instances. I think it should.


> - RFC6241 clearly states that whitespace has to be considered part of =
a string
>=20
> Our responsibility is not just to follow the standard, but to be =
intuitive.  Trimming whitespace from a string is not intuitive, I would =
rather call it surprising.

+1

Lada

>=20
> Also if we would blindly follow RFC6241:=20
> "Leading and trailing whitespace characters are ignored, but any =
whitespace characters within a block of text characters are not ignored =
or modified."
> would mean that you would never ever get a content match for  the =
string "  aa" as ignoring  the whitespace in the content match input =
means, the content match input is first converted to "aa" and that is =
what we try to match, which will never be equal to "  aa". =20
>=20
> regards Balazs
>=20
> On 2015-02-23 22:51, Andy Bierman wrote:
>> On Mon, Feb 23, 2015 at 1:07 PM, t.petch 
>>  wrote:
>>=20
>>> ----- Original Message -----
>>> From: "Ladislav Lhotka"=20
>>> 
>>>=20
>>> To: "Martin Bj=C3=B6rklund"=20
>>> 
>>>=20
>>> Cc: "Netconf"=20
>>> 
>>> ; "Peter Labraaten"
>>>=20
>>> 
>>>=20
>>> Sent: Monday, February 23, 2015 8:16 PM
>>>=20
>>>>> On 23 Feb 2015, at 20:42, Martin Bjorklund 
>>>>>  wrote:
>>>>>=20
>>>>> Ladislav Lhotka=20
>>>>> 
>>>>>  wrote:
>>>>>=20
>>>>>>> On 23 Feb 2015, at 17:29, Andy Bierman 
>>>>>>>  wrote:
>>>>>>>=20
>>>>>>> On Mon, Feb 23, 2015 at 5:21 AM, Ladislav Lhotka=20
>>>>>>> 
>>>>>>>=20
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> Balazs Lengyel 
>>>>>>>>  writes:
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> Hello,
>>>>>>>>> I assume that " hello" with the leading space is a perfectly =
OK
>>>>>>>>>=20
>>> value
>>>=20
>>>>>>>>> in
>>>>>>>>> Netconf/YANG for a string leaf. I also think that the " hello"
>>>>>>>>>=20
>>> string
>>>=20
>>>>>>>>> is
>>>>>>>>> not the same as the "hello" string without the space.
>>>>>>>>> However=20
>>>>>>>>> https://tools.ietf.org/html/rfc6241#section-6.2.5
>>>>>>>>>  part
>>>>>>>>>=20
>>> of the
>>>=20
>>>>>>>>> Netconf RFC says about filtering
>>>>>>>>>=20
>>>>>>>>> "Leading and trailing whitespace characters are ignored, but =
any
>>>>>>>>>      whitespace characters within a block of text characters =
are
>>>>>>>>>=20
>>> not
>>>=20
>>>>>>>>>      ignored or modified."
>>>>>>>>>=20
>>>>>>>>> IMHO this is an error for YANG string leafs. It is perfectly =
OK
>>>>>>>>>=20
>>> to
>>>=20
>>>>>>>>> convert an integer "  1" into "1" but converting the string "
>>>>>>>>>=20
>>> hello"
>>>=20
>>>>>>>>> into "hello" is changing its content. So there should be an
>>>>>>>>>=20
>>> errata
>>>=20
>>>>>>>>> stating that for string type content all white space content =
is
>>>>>>>>> considered during filtering.
>>>>>>>>>=20
>>>>>>>>> Agree? If you do not agree, how am I supposed to filter for "
>>>>>>>>>=20
>>> hello"
>>>=20
>>>>>>>>> instead of "hello"?
>>>>>>>>>=20
>>>>>>>> I agree. It is perfectly legal (albeit hardly recommendable) to
>>>>>>>>=20
>>> define
>>>=20
>>>>>>>> the following enums in YANG, and they have to be regarded as
>>>>>>>>=20
>>> distinct
>>>=20
>>>>>>>> by
>>>>>>>> a NETCONF server:
>>>>>>>>=20
>>>>>>>> enum "foo";
>>>>>>>> enum " foo";
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> This is not allowed,  =46rom 9.6.4:
>>>>>>>=20
>>>>>>>  It takes as an argument a string which is the assigned name.  =
The
>>>>>>>=20
>>>>>>>  string MUST NOT be empty and MUST NOT have any leading or
>>>>>>>=20
>>> trailing
>>>=20
>>>>>>>  whitespace characters.  The use of Unicode control codes SHOULD
>>>>>>>=20
>>> be
>>>=20
>>>>>>>  avoided.
>>>>>>>=20
>>>>>> OK, sorry, my fault. But still, e.g. list keys =E2=80=9Cfoo=E2=80=9D=
 and =E2=80=9C foo=E2=80=9D
>>>>>>=20
>>> must
>>>=20
>>>>>> be considered different.
>>>>>>=20
>>>>> Yes, they are absolutely different.  But you cannot use subtree
>>>>> filtering to get just one of them.  (You can get both, and then
>>>>>=20
>>> apply
>>>=20
>>>>> client-side logic to single out the one you actually were =
interested
>>>>> in).
>>>>>=20
>>>> This is not how I read the text that Balazs cited: it says that
>>>>=20
>>> leading and trailing whitespace is ignored, and I understand it is
>>> ignored in content match nodes. Therefore, the list entry with =E2=80=9C=
 foo=E2=80=9D
>>> key must be inaccessible, which is exactly what Balazs concluded.
>>>=20
>>> Lada
>>>=20
>>> I agree.  My reading of the text is that stripping the spaces =
applies to
>>> the content match node and that no such normalisation is performed =
on
>>> the data base element ("the leaf  node element content").
>>>=20
>>>=20
>> I think the issue Balazs raised is questioning why the server would =
alter
>> the filter match expression.  Why is this a feature?  The client can =
create
>> string leafs with leading and trailing whitespace, but not filter =
them
>> with a content match node.
>>=20
>>=20
>>> Tom Petch
>>>=20
>>>=20
>> Andy
>>=20
>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>>>> Trimming whitespace in XML *elements* breaks
>>>>>> all XML tools.
>>>>>>=20
>>>>> Not true.  Whitespaces are preserved in XML, yes, but that just
>>>>>=20
>>> means
>>>=20
>>>>> that generic tools will not do any trimming.  Any compliant =
subtree
>>>>> filtering implementation will thus have to do the trimming after =
XML
>>>>> parsing.
>>>>>=20
>>>> Yes, but it means a complication, e.g. for converting subtree =
filters
>>>>=20
>>> to XPath, also because this whitespace trimming is not the same as =
the
>>> effect of the normalize-space function.
>>>=20
>>>> Lada
>>>>=20
>>>>=20
>>>>>=20
>>>>> /martin
>>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Netconf mailing list
>>>>=20
>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>=20
>>>>=20
>>>>=20
>>> _______________________________________________
>>> Netconf mailing list
>>>=20
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>> _______________________________________________
>> Netconf mailing list
>>=20
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320                        Tel: +36-1-437-7320
> Mobile: +36-70-330-7909              email:=20
> Balazs.Lengyel@ericsson.com
> =20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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





From nobody Tue Feb 24 02:12:43 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C991A03AB for ; Tue, 24 Feb 2015 02:12:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4f6prR13uTv for ; Tue, 24 Feb 2015 02:12:41 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A47A1A0194 for ; Tue, 24 Feb 2015 02:12:41 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D1306F85; Tue, 24 Feb 2015 11:12:39 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 68S0YNcW-44n; Tue, 24 Feb 2015 11:12:32 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Feb 2015 11:12:39 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDE5A20037; Tue, 24 Feb 2015 11:12:38 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jhwnbz4X72Sz; Tue, 24 Feb 2015 11:12:38 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24C0120036; Tue, 24 Feb 2015 11:12:38 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 6A25A323653A; Tue, 24 Feb 2015 11:12:38 +0100 (CET)
Date: Tue, 24 Feb 2015 11:12:38 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150224101238.GA49982@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Balazs Lengyel , Netconf 
References:    <20150223.204254.464201352091987038.mbj@tail-f.com>  <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net>  <54EC46E1.7020502@ericsson.com> <679A7F27-0BE6-4DCA-BBA4-3378043BD3CC@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <679A7F27-0BE6-4DCA-BBA4-3378043BD3CC@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC?
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, 24 Feb 2015 10:12:42 -0000

On Tue, Feb 24, 2015 at 11:04:40AM +0100, Ladislav Lhotka wrote:
> 
> Actually, RFC 6020 says nothing about the handling of whitespace in numeric instances. I think it should.
>

RFC 6020 section 9.2:

   An integer value is lexically represented as an optional sign ("+" or
   "-"), followed by a sequence of decimal digits.  If no sign is
   specified, "+" is assumed.

[...]

   The canonical form of a positive integer does not include the sign
   "+".  Leading zeros are prohibited.  The value zero is represented as
   "0".

I find this pretty clear.

/js

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


From nobody Tue Feb 24 02:18:53 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7151A038F for ; Tue, 24 Feb 2015 02:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MOlN0yeqq7n for ; Tue, 24 Feb 2015 02:18:51 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D821A036E for ; Tue, 24 Feb 2015 02:18:51 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:f073:a7bf:5b0c:84c4] (unknown [IPv6:2001:718:1a02:1:f073:a7bf:5b0c:84c4]) by mail.nic.cz (Postfix) with ESMTPSA id ADBBA140A50; Tue, 24 Feb 2015 11:18:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1424773129; bh=G0XrBvPGWtFSaoAQPz2QQiVJeyxHhNrEJiwkjrm1XBY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xsvjHhjqKCQ6u4JsB4quegHBX0bkRsgfXk+8x/SBmqWVzjiszmaEkAVtCGY5pTl6t SIfHj9xJAJXF8pkpwmcSIMH4R/pGJz9OY/Tlin3tJBKdbGZ8MBrC5Iz4iKl16NMxi4 wfcIa3DjAympXMGYSUc183+h5fYvuJRV4ac2n8ss=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ladislav Lhotka 
In-Reply-To: <20150224101238.GA49982@elstar.local>
Date: Tue, 24 Feb 2015 11:18:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9905FAF6-130E-46CE-BDAB-B0F9319C8243@nic.cz>
References:    <20150223.204254.464201352091987038.mbj@tail-f.com>  <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net>  <54EC46E1.7020502@ericsson.com> <679A7F27-0BE6-4DCA-BBA4-3378043BD3CC@nic.cz> <20150224101238.GA49982@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.2070.6)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC?
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, 24 Feb 2015 10:18:52 -0000

> On 24 Feb 2015, at 11:12, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Feb 24, 2015 at 11:04:40AM +0100, Ladislav Lhotka wrote:
>>=20
>> Actually, RFC 6020 says nothing about the handling of whitespace in =
numeric instances. I think it should.
>>=20
>=20
> RFC 6020 section 9.2:
>=20
>   An integer value is lexically represented as an optional sign ("+" =
or
>   "-"), followed by a sequence of decimal digits.  If no sign is
>   specified, "+" is assumed.

OK, but then Balazs=E2=80=99 advice regarding numbers =E2=80=9C  +1=E2=80=9D=
 and =E2=80=9C1=E2=80=9D is incorrect.

Lada

>=20
> [...]
>=20
>   The canonical form of a positive integer does not include the sign
>   "+".  Leading zeros are prohibited.  The value zero is represented =
as
>   "0".
>=20
> I find this pretty clear.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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





From nobody Tue Feb 24 02:48:41 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C761A1A59 for ; Tue, 24 Feb 2015 02:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.177
X-Spam-Level: 
X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 cki__7-LPzMT for ; Tue, 24 Feb 2015 02:48:39 -0800 (PST)
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 C861D1A038E for ; Tue, 24 Feb 2015 02:48:38 -0800 (PST)
X-AuditID: c1b4fb30-f79626d000003cf6-c6-54ec570479a1
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CB.F9.15606.4075CE45; Tue, 24 Feb 2015 11:48:36 +0100 (CET)
Received: from [159.107.197.114] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Tue, 24 Feb 2015 11:48:36 +0100
Message-ID: <54EC5703.50302@ericsson.com>
Date: Tue, 24 Feb 2015 11:48:35 +0100
From: Balazs Lengyel 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Ladislav Lhotka , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGU=?= =?UTF-8?B?cg==?= 
References:    <20150223.204254.464201352091987038.mbj@tail-f.com>  <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net>  <54EC46E1.7020502@ericsson.com> <679A7F27-0BE6-4DCA-BBA4-3378043BD3CC@nic.cz> <20150224101238.GA49982@elstar.local> <9905FAF6-130E-46CE-BDAB-B0F9319C8243@nic.cz>
In-Reply-To: <9905FAF6-130E-46CE-BDAB-B0F9319C8243@nic.cz>
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM+JvjS5L+JsQg6vH9S2ubvzJaHFh1Vw2 i6mbbrM6MHssWfKTyWPDAU+PTZfvMAYwR3HZpKTmZJalFunbJXBlrHm2n7XggljFi1X72RsY /wh0MXJySAiYSDRO7WCBsMUkLtxbz9bFyMUhJHCEUaL3STsjhLOWUeLkmpVgVbwCmhLzOjuZ QGwWAVWJTV+72EFsNgEjian958FqRAWiJGaff8AKUS8ocXLmExaQQSIC7YwST/+cAGtmFpCT WPyjB8wWFkiSuPO/E2rbPBaJviMdYFM5BawkNq17ywbRoCHROmcuO4QtL9G8dTYziC0EFH94 4S/rBEbBWUgWzkLSMgtJywJG5lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgWF8cMtvgx2M L587HmIU4GBU4uEtUHwTIsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGRoVPxwN2Ji1gb155TVSnLEGruzrl5EeeP7+y9p3XUdbcmn84LWjFHIHe4KDj0ssm qESecQnkMVym9vH69GsiVvIXQ6INwma6fPWbOU2bOb5++a8P/U25p4O/5Sw+tKlQmM2p2vVR lMom9QrXZ6mCbwvfHvqcGlXnuHrBm/U9t3fdPTuD+WrwRSWW4oxEQy3mouJEAD0vOLlEAgAA
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC?
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, 24 Feb 2015 10:48:40 -0000


  
    
  
  
    Hello Lada, 

    I wrote:

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

    - Comparing values
        does not and should not mean the same thing for strings and
        integers, 

        while the string "    aa  " and "aa" are different 

        the numbers  "   +1" and "1" are not.

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

    So as I see it (in agreement with RFC6020)  the following are all
    equivalent for an integer type:

    "1" "+1" "  1"

    Balazs

    

    
On 2015-02-24 11:18, Ladislav Lhotka
      wrote:

    

    

      

      

        
On 24 Feb 2015, at 11:12, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Tue, Feb 24, 2015 at 11:04:40AM +0100, Ladislav Lhotka wrote:


        

          
Actually, RFC 6020 says nothing about the handling of whitespace in numeric instances. I think it should.



        

        
RFC 6020 section 9.2:

  An integer value is lexically represented as an optional sign ("+" or
  "-"), followed by a sequence of decimal digits.  If no sign is
  specified, "+" is assumed.


      

      
OK, but then Balazs’ advice regarding numbers “  +1” and “1” is incorrect.

Lada



      

        
[...]

  The canonical form of a positive integer does not include the sign
  "+".  Leading zeros are prohibited.  The value zero is represented as
  "0".

I find this pretty clear.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>


      

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








    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Tue Feb 24 02:50:52 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B891A038E for ; Tue, 24 Feb 2015 02:50:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wae5JMDuP4GS for ; Tue, 24 Feb 2015 02:50:49 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745461A0019 for ; Tue, 24 Feb 2015 02:50:49 -0800 (PST)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 0B3EC13FE2D; Tue, 24 Feb 2015 11:50:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1424775048; bh=Vk8C9S2nHLO5f1sh45T7CYCY21ujV3phM8oN/H2G3sQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=owY9g39VbuzTKoiLCStHcsgN9aeaZ6PxwI1C3hFJmAr4lkd209yVhv05Ctwxr9BY4 vd1NS4NwtnVsmFQ0fgWKYkVSrDfWlUzqj44y/RadiffZ30TsrdT3KN3ORfcj1ZIou/ Cxe1wgcghRJvjnuP+0ycQnwTRDFXW9dMtaaTsb7s=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ladislav Lhotka 
In-Reply-To: <54EC5703.50302@ericsson.com>
Date: Tue, 24 Feb 2015 11:50:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <20150223.204254.464201352091987038.mbj@tail-f.com>  <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net>  <54EC46E1.7020502@ericsson.com> <679A7F27-0BE6-4DCA-BBA4-3378043BD3CC@nic.cz> <20150224101238.GA49982@elstar.local> <9905FAF6-130E-46CE-BDAB-B0F9319C8243@nic.cz> <54EC5703.50302@ericsson.com>
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.2070.6)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC?
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, 24 Feb 2015 10:50:51 -0000

> On 24 Feb 2015, at 11:48, Balazs Lengyel  =
wrote:
>=20
> Hello Lada,=20
> I wrote:
> --------------------------
> - Comparing values does not and should not mean the same thing for =
strings and integers,=20
> while the string "    aa  " and "aa" are different=20
> the numbers  "   +1" and "1" are not.
> --------------------------
> So as I see it (in agreement with RFC6020)  the following are all =
equivalent for an integer type:
> "1" "+1" "  1=E2=80=9D

The third form is an invalid lexical representation.

Lada

> Balazs
>=20
> On 2015-02-24 11:18, Ladislav Lhotka wrote:
>>> On 24 Feb 2015, at 11:12, Juergen Schoenwaelder =

>>>  wrote:
>>>=20
>>> On Tue, Feb 24, 2015 at 11:04:40AM +0100, Ladislav Lhotka wrote:
>>>=20
>>>> Actually, RFC 6020 says nothing about the handling of whitespace in =
numeric instances. I think it should.
>>>>=20
>>>>=20
>>> RFC 6020 section 9.2:
>>>=20
>>>   An integer value is lexically represented as an optional sign ("+" =
or
>>>   "-"), followed by a sequence of decimal digits.  If no sign is
>>>   specified, "+" is assumed.
>>>=20
>> OK, but then Balazs=E2=80=99 advice regarding numbers =E2=80=9C  =
+1=E2=80=9D and =E2=80=9C1=E2=80=9D is incorrect.
>>=20
>> Lada
>>=20
>>=20
>>> [...]
>>>=20
>>>   The canonical form of a positive integer does not include the sign
>>>   "+".  Leading zeros are prohibited.  The value zero is represented =
as
>>>   "0".
>>>=20
>>> I find this pretty clear.
>>>=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        =20
>>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320                        Tel: +36-1-437-7320
> Mobile: +36-70-330-7909              email:=20
> Balazs.Lengyel@ericsson.com
> =20
>=20

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





From nobody Tue Feb 24 03:09: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 587E21A044F for ; Tue, 24 Feb 2015 03:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2NdalL58CLj for ; Tue, 24 Feb 2015 03:09:24 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7EEA1A0263 for ; Tue, 24 Feb 2015 03:09:24 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 98853A15; Tue, 24 Feb 2015 12:09:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zI5VA786jG1E; Tue, 24 Feb 2015 12:09:16 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Feb 2015 12:09:23 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5A8E20038; Tue, 24 Feb 2015 12:09:22 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nd7kPtPnMSf8; Tue, 24 Feb 2015 12:09:22 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 427C420036; Tue, 24 Feb 2015 12:09:21 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 7E93A3236848; Tue, 24 Feb 2015 12:09:21 +0100 (CET)
Date: Tue, 24 Feb 2015 12:09:21 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150224110921.GA50273@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Balazs Lengyel , Netconf 
References: <20150223.204254.464201352091987038.mbj@tail-f.com>  <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net>  <54EC46E1.7020502@ericsson.com> <679A7F27-0BE6-4DCA-BBA4-3378043BD3CC@nic.cz> <20150224101238.GA49982@elstar.local> <9905FAF6-130E-46CE-BDAB-B0F9319C8243@nic.cz> <54EC5703.50302@ericsson.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC?
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, 24 Feb 2015 11:09:26 -0000

On Tue, Feb 24, 2015 at 11:50:52AM +0100, Ladislav Lhotka wrote:
> 
> > On 24 Feb 2015, at 11:48, Balazs Lengyel  wrote:
> > 
> > Hello Lada, 
> > I wrote:
> > --------------------------
> > - Comparing values does not and should not mean the same thing for strings and integers, 
> > while the string "    aa  " and "aa" are different 
> > the numbers  "   +1" and "1" are not.
> > --------------------------
> > So as I see it (in agreement with RFC6020)  the following are all equivalent for an integer type:
> > "1" "+1" "  1”
> 
> The third form is an invalid lexical representation.
> 

And the server's canonical representation is "1".

/js

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


From nobody Tue Feb 24 03:34: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 E70AD1A0389 for ; Tue, 24 Feb 2015 03:33:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-P6bc322GlI for ; Tue, 24 Feb 2015 03:33:58 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352A21A0013 for ; Tue, 24 Feb 2015 03:33:58 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-b9-54ec61a3eea8
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EC.95.24955.3A16CE45; Tue, 24 Feb 2015 12:33:56 +0100 (CET)
Received: from [159.107.197.114] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.210.2; Tue, 24 Feb 2015 12:33:55 +0100
Message-ID: <54EC61A3.5010106@ericsson.com>
Date: Tue, 24 Feb 2015 12:33:55 +0100
From: Balazs Lengyel 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Ladislav Lhotka 
References:    <20150223.204254.464201352091987038.mbj@tail-f.com>  <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net>  <54EC46E1.7020502@ericsson.com> <679A7F27-0BE6-4DCA-BBA4-3378043BD3CC@nic.cz> <20150224101238.GA49982@elstar.local> <9905FAF6-130E-46CE-BDAB-B0F9319C8243@nic.cz> <54EC5703.50302@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvje6SxDchBk9msVhc3fiT0eLCqrls FlM33WZ1YPZYsuQnk8eGA54emy7fYQxgjuKySUnNySxLLdK3S+DK+P93BlPBC46K2auvMzcw 3mHrYuTgkBAwkVj226OLkRPIFJO4cG89UJiLQ0jgCKPEr5d/2EASQgJrGSXuXLIAqecV0JbY NdUbJMwioCrx5c9qZhCbTcBIYmr/eRYQW1QgSmL2+QesIDavgKDEyZlPwOIiAsoSFyf8BLOZ BQol9jzfDVYjLJAkced/JyPE3lcsEjdmrQMbyilgJfHhzQ9miAYLiZnzzzNC2PISzVtnM0Pc piHx8MJf1gmMgrOQ7JuFpGUWkpYFjMyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQLD9+CW 36o7GC+/cTzEKMDBqMTDW6D4JkSINbGsuDL3EKM0B4uSOK+d8aEQIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYyB0yNPnz01seDfhuO+mT+vbpr3Y0Utf7HcNutTe7NqHO1q5/tMLO0+sOv8 sur646H6C7OmPrv2P0brQxFPiO6Bi7zJ+5imTt/c+dHz4q0+C+9cy79rdx+725MmujY4fQ+7 md/ebeXdL9o6HMxDri/SUFqZe+qJybWiM+9krpQ/M+V5/vPdi6anSizFGYmGWsxFxYkAAXap 80ACAAA=
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC?
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, 24 Feb 2015 11:34:00 -0000

On 2015-02-24 11:50, Ladislav Lhotka wrote:
>> On 24 Feb 2015, at 11:48, Balazs Lengyel  wrote:
>>
>> Hello Lada,
>> I wrote:
>> --------------------------
>> - Comparing values does not and should not mean the same thing for strings and integers,
>> while the string "    aa  " and "aa" are different
>> the numbers  "   +1" and "1" are not.
>> --------------------------
>> So as I see it (in agreement with RFC6020)  the following are all equivalent for an integer type:
>> "1" "+1" "  1”
> The third form is an invalid lexical representation.
>
> Lada
[BALAZS]: yes true,
but following the Postel principle (be liberal in what you accept) and 
seeing that whitespace is sometimes
added just for formating, and that this is not a source of possible 
misunderstandings for an integer, I see it
OK to accept it by trimming leading and trailing whitespace.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Tue Feb 24 03:40: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 106881A0389 for ; Tue, 24 Feb 2015 03:40:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tk85j97_HW2 for ; Tue, 24 Feb 2015 03:40:02 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B77F1A03A9 for ; Tue, 24 Feb 2015 03:40:02 -0800 (PST)
Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.93.16; Tue, 24 Feb 2015 11:39:40 +0000
Message-ID: <01af01d05026$4d38ece0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Balazs Lengyel , 
References:    <20150223.204254.464201352091987038.mbj@tail-f.com>  <003b01d04fac$d6f516e0$4001a8c0@gateway.2wire.net>  <54EC46E1.7020502@ericsson.com>
Date: Tue, 24 Feb 2015 11:37:34 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.167.59]
X-ClientProxiedBy: DB4PR03CA0016.eurprd03.prod.outlook.com (25.160.39.154) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005004); SRVR:DB3PR07MB060; 
X-Forefront-PRVS: 04976078F0
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(51704005)(199003)(377424004)(377454003)(252514010)(13464003)(19580405001)(86362001)(81816999)(575784001)(44716002)(33646002)(66066001)(61296003)(76176999)(101416001)(23676002)(81686999)(62236002)(46102003)(62966003)(93886004)(106356001)(77156002)(116806002)(44736004)(50226001)(122386002)(50986999)(40100003)(19580395003)(105586002)(1456003)(107886001)(5820100001)(64706001)(87976001)(84392001)(68736005)(14496001)(1556002)(47776003)(97736003)(50466002)(77096005)(15975445007)(92566002)(42186005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060;
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2015 11:39:40.3577 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060
Archived-At: 
Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC?
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, 24 Feb 2015 11:40:05 -0000

----- Original Message -----
From: "Balazs Lengyel" 
To: 
Sent: Tuesday, February 24, 2015 9:39 AM
> Hello,
> Although this might not be 100% standard compliant, I wrote the
following internal guideline in Ericsson:
> - When Netconf was designed they tried to make it data model agnostic
as there was no accepted data modeling language at the time. Thus it
would handle string attributes the same way as integer or binary
attributes. While separating layers (protocol versus data model) is
generally a good idea, this level of "data model agnostic" treatment is
taking it too far, it is a mistake.
> - Comparing values does not and should not mean the same thing for
strings and integers,
> while the string "    aa  " and "aa" are different
> the numbers  "   +1" and "1" are not.
> - RFC6241 clearly states that whitespace has to be considered part of
a string
>
> Our responsibility is not just to follow the standard, but to be
intuitive.  Trimming whitespace from a string is not intuitive, I would
rather call it surprising.
>
> Also if we would blindly follow RFC6241:
> "Leading and trailing whitespace characters are ignored, but any
whitespace characters within a block of text characters are not ignored
or modified."
> would mean that you would never ever get a content match for  the
string "  aa" as ignoring  the whitespace in the content match input
means, the content match input is first converted to "aa" and that is
what we try to match, which will never be equal to "  aa".

I have a certain sympathy with the author of the text in RFC6241.  You
would say that

Balazs Lengyel
and
Balazs Lengyel
are different because the second one is actually
"Balazs Lengyel  "
to which I would say what an opportunity for a phishing attack!  I
cannot remember if attacks based on something like this were happening
10 years ago, but I have some distant memory thereof.

It is unfortunate that the canonical form in Netconf is not the same as
in YANG but I would find the YANG form the more surprising.  Some
databases I deal with even turn some punctuation characters into white
space before performing a comparison.  Again, some databases have stem
searches with a range of regular expressions in which case the search
you are looking for would be no problem.

Tom Petch





>
> regards Balazs
>
>
> On 2015-02-23 22:51, Andy Bierman wrote:
>
> On Mon, Feb 23, 2015 at 1:07 PM, t.petch  wrote:
> ----- Original Message -----
> From: "Ladislav Lhotka" 
> To: "Martin Björklund" 
> Cc: "Netconf" ; "Peter Labraaten"
> 
> Sent: Monday, February 23, 2015 8:16 PM
> On 23 Feb 2015, at 20:42, Martin Bjorklund  wrote:
>
> Ladislav Lhotka  wrote:
> On 23 Feb 2015, at 17:29, Andy Bierman  wrote:
>
> On Mon, Feb 23, 2015 at 5:21 AM, Ladislav Lhotka 
> wrote:
> Balazs Lengyel  writes:
>
> Hello,
> I assume that " hello" with the leading space is a perfectly OK
> value
> in
> Netconf/YANG for a string leaf. I also think that the " hello"
> string
> is
> not the same as the "hello" string without the space.
> However https://tools.ietf.org/html/rfc6241#section-6.2.5 part
> of the
> Netconf RFC says about filtering
>
> "Leading and trailing whitespace characters are ignored, but any
>      whitespace characters within a block of text characters are
> not
>      ignored or modified."
>
> IMHO this is an error for YANG string leafs. It is perfectly OK
> to
> convert an integer "  1" into "1" but converting the string "
> hello"
> into "hello" is changing its content. So there should be an
> errata
> stating that for string type content all white space content is
> considered during filtering.
>
> Agree? If you do not agree, how am I supposed to filter for "
> hello"
> instead of "hello"?
> I agree. It is perfectly legal (albeit hardly recommendable) to
> define
> the following enums in YANG, and they have to be regarded as
> distinct
> by
> a NETCONF server:
>
> enum "foo";
> enum " foo";
>
> This is not allowed,  From 9.6.4:
>
>  It takes as an argument a string which is the assigned name.  The
>  string MUST NOT be empty and MUST NOT have any leading or
> trailing
>  whitespace characters.  The use of Unicode control codes SHOULD
> be
>  avoided.
> OK, sorry, my fault. But still, e.g. list keys “foo” and “
foo”
> must
> be considered different.
> Yes, they are absolutely different.  But you cannot use subtree
> filtering to get just one of them.  (You can get both, and then
> apply
> client-side logic to single out the one you actually were interested
> in).
> This is not how I read the text that Balazs cited: it says that
> leading and trailing whitespace is ignored, and I understand it is
> ignored in content match nodes. Therefore, the list entry with “
foo”
> key must be inaccessible, which is exactly what Balazs concluded.
>
> Lada
>
> I agree.  My reading of the text is that stripping the spaces applies
to
> the content match node and that no such normalisation is performed on
> the data base element ("the leaf  node element content").
>
> I think the issue Balazs raised is questioning why the server would
alter
> the filter match expression.  Why is this a feature?  The client can
create
> string leafs with leading and trailing whitespace, but not filter them
> with a content match node.
>
> Tom Petch
>
> Andy
>
>
>
>
>
>
> Trimming whitespace in XML *elements* breaks
> all XML tools.
> Not true.  Whitespaces are preserved in XML, yes, but that just
> means
> that generic tools will not do any trimming.  Any compliant subtree
> filtering implementation will thus have to do the trimming after XML
> parsing.
> Yes, but it means a complication, e.g. for converting subtree filters
> to XPath, also because this whitespace trimming is not the same as the
> effect of the normalize-space function.
> Lada
>
>
> /martin
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320                        Tel: +36-1-437-7320
> Mobile: +36-70-330-7909              email:
Balazs.Lengyel@ericsson.com
>


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


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


From nobody Tue Feb 24 10:17: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 683391A8775 for ; Tue, 24 Feb 2015 10:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-hpqinY2aYm for ; Tue, 24 Feb 2015 10:17:27 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 74BEE1A8769 for ; Tue, 24 Feb 2015 10:17:27 -0800 (PST)
Received: from localhost (host-90-236-134-251.mobileonline.telia.com [90.236.134.251]) by mail.tail-f.com (Postfix) with ESMTPSA id B4B3A128048E; Tue, 24 Feb 2015 19:17:25 +0100 (CET)
Date: Tue, 24 Feb 2015 19:17:19 +0100 (CET)
Message-Id: <20150224.191719.1520406386509954594.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20150223.204254.464201352091987038.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netconf@ietf.org, peter.labraaten@ericsson.com
Subject: Re: [Netconf] Unable to filter strings with leading whitespace - errata on Netconf RFC?
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, 24 Feb 2015 18:17:29 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjMgRmVi
IDIwMTUsIGF0IDIwOjQyLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6
DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g
DQo+ID4+PiBPbiAyMyBGZWIgMjAxNSwgYXQgMTc6MjksIEFuZHkgQmllcm1hbiA8YW5keUB5dW1h
d29ya3MuY29tPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gT24gTW9uLCBGZWIgMjMsIDIwMTUgYXQg
NToyMSBBTSwgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6Pg0KPiA+Pj4gd3JvdGU6DQo+
ID4+Pj4gQmFsYXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT4gd3JpdGVz
Og0KPiA+Pj4+IA0KPiA+Pj4+PiBIZWxsbywNCj4gPj4+Pj4gSSBhc3N1bWUgdGhhdCAiIGhlbGxv
IiB3aXRoIHRoZSBsZWFkaW5nIHNwYWNlIGlzIGEgcGVyZmVjdGx5IE9LIHZhbHVlDQo+ID4+Pj4+
IGluDQo+ID4+Pj4+IE5ldGNvbmYvWUFORyBmb3IgYSBzdHJpbmcgbGVhZi4gSSBhbHNvIHRoaW5r
IHRoYXQgdGhlICIgaGVsbG8iIHN0cmluZw0KPiA+Pj4+PiBpcw0KPiA+Pj4+PiBub3QgdGhlIHNh
bWUgYXMgdGhlICJoZWxsbyIgc3RyaW5nIHdpdGhvdXQgdGhlIHNwYWNlLg0KPiA+Pj4+PiBIb3dl
dmVyIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjQxI3NlY3Rpb24tNi4yLjUgcGFy
dCBvZiB0aGUNCj4gPj4+Pj4gTmV0Y29uZiBSRkMgc2F5cyBhYm91dCBmaWx0ZXJpbmcNCj4gPj4+
Pj4gDQo+ID4+Pj4+ICJMZWFkaW5nIGFuZCB0cmFpbGluZyB3aGl0ZXNwYWNlIGNoYXJhY3RlcnMg
YXJlIGlnbm9yZWQsIGJ1dCBhbnkNCj4gPj4+Pj4gICAgICB3aGl0ZXNwYWNlIGNoYXJhY3RlcnMg
d2l0aGluIGEgYmxvY2sgb2YgdGV4dCBjaGFyYWN0ZXJzIGFyZSBub3QNCj4gPj4+Pj4gICAgICBp
Z25vcmVkIG9yIG1vZGlmaWVkLiINCj4gPj4+Pj4gDQo+ID4+Pj4+IElNSE8gdGhpcyBpcyBhbiBl
cnJvciBmb3IgWUFORyBzdHJpbmcgbGVhZnMuIEl0IGlzIHBlcmZlY3RseSBPSyB0bw0KPiA+Pj4+
PiBjb252ZXJ0IGFuIGludGVnZXIgIiAgMSIgaW50byAiMSIgYnV0IGNvbnZlcnRpbmcgdGhlIHN0
cmluZyAiIGhlbGxvIg0KPiA+Pj4+PiBpbnRvICJoZWxsbyIgaXMgY2hhbmdpbmcgaXRzIGNvbnRl
bnQuIFNvIHRoZXJlIHNob3VsZCBiZSBhbiBlcnJhdGENCj4gPj4+Pj4gc3RhdGluZyB0aGF0IGZv
ciBzdHJpbmcgdHlwZSBjb250ZW50IGFsbCB3aGl0ZSBzcGFjZSBjb250ZW50IGlzDQo+ID4+Pj4+
IGNvbnNpZGVyZWQgZHVyaW5nIGZpbHRlcmluZy4NCj4gPj4+Pj4gDQo+ID4+Pj4+IEFncmVlPyBJ
ZiB5b3UgZG8gbm90IGFncmVlLCBob3cgYW0gSSBzdXBwb3NlZCB0byBmaWx0ZXIgZm9yICIgaGVs
bG8iDQo+ID4+Pj4+IGluc3RlYWQgb2YgImhlbGxvIj8NCj4gPj4+PiANCj4gPj4+PiBJIGFncmVl
LiBJdCBpcyBwZXJmZWN0bHkgbGVnYWwgKGFsYmVpdCBoYXJkbHkgcmVjb21tZW5kYWJsZSkgdG8g
ZGVmaW5lDQo+ID4+Pj4gdGhlIGZvbGxvd2luZyBlbnVtcyBpbiBZQU5HLCBhbmQgdGhleSBoYXZl
IHRvIGJlIHJlZ2FyZGVkIGFzIGRpc3RpbmN0DQo+ID4+Pj4gYnkNCj4gPj4+PiBhIE5FVENPTkYg
c2VydmVyOg0KPiA+Pj4+IA0KPiA+Pj4+IGVudW0gImZvbyI7DQo+ID4+Pj4gZW51bSAiIGZvbyI7
DQo+ID4+Pj4gDQo+ID4+PiANCj4gPj4+IFRoaXMgaXMgbm90IGFsbG93ZWQsICBGcm9tIDkuNi40
Og0KPiA+Pj4gDQo+ID4+PiAgSXQgdGFrZXMgYXMgYW4gYXJndW1lbnQgYSBzdHJpbmcgd2hpY2gg
aXMgdGhlIGFzc2lnbmVkIG5hbWUuICBUaGUNCj4gPj4+ICBzdHJpbmcgTVVTVCBOT1QgYmUgZW1w
dHkgYW5kIE1VU1QgTk9UIGhhdmUgYW55IGxlYWRpbmcgb3IgdHJhaWxpbmcNCj4gPj4+ICB3aGl0
ZXNwYWNlIGNoYXJhY3RlcnMuICBUaGUgdXNlIG9mIFVuaWNvZGUgY29udHJvbCBjb2RlcyBTSE9V
TEQgYmUNCj4gPj4+ICBhdm9pZGVkLg0KPiA+PiANCj4gPj4gT0ssIHNvcnJ5LCBteSBmYXVsdC4g
QnV0IHN0aWxsLCBlLmcuIGxpc3Qga2V5cyDigJxmb2/igJ0gYW5kIOKAnCBmb2/igJ0gbXVzdA0K
PiA+PiBiZSBjb25zaWRlcmVkIGRpZmZlcmVudC4NCj4gPiANCj4gPiBZZXMsIHRoZXkgYXJlIGFi
c29sdXRlbHkgZGlmZmVyZW50LiAgQnV0IHlvdSBjYW5ub3QgdXNlIHN1YnRyZWUNCj4gPiBmaWx0
ZXJpbmcgdG8gZ2V0IGp1c3Qgb25lIG9mIHRoZW0uICAoWW91IGNhbiBnZXQgYm90aCwgYW5kIHRo
ZW4gYXBwbHkNCj4gPiBjbGllbnQtc2lkZSBsb2dpYyB0byBzaW5nbGUgb3V0IHRoZSBvbmUgeW91
IGFjdHVhbGx5IHdlcmUgaW50ZXJlc3RlZA0KPiA+IGluKS4NCj4gDQo+IFRoaXMgaXMgbm90IGhv
dyBJIHJlYWQgdGhlIHRleHQgdGhhdCBCYWxhenMgY2l0ZWQ6IGl0IHNheXMgdGhhdA0KPiBsZWFk
aW5nIGFuZCB0cmFpbGluZyB3aGl0ZXNwYWNlIGlzIGlnbm9yZWQsIGFuZCBJIHVuZGVyc3RhbmQg
aXQgaXMNCj4gaWdub3JlZCBpbiBjb250ZW50IG1hdGNoIG5vZGVzLg0KDQpZZXMsIHlvdSdyZSBy
aWdodC4gIEkgZ290IGl0IHdyb25nLg0KDQoNCi9tYXJ0aW4NCg==


From nobody Tue Feb 24 12:21:33 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46601A8861 for ; Tue, 24 Feb 2015 12:21:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C_sowzsLw8s for ; Tue, 24 Feb 2015 12:21:31 -0800 (PST)
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7233A1A6EDE for ; Tue, 24 Feb 2015 12:21:31 -0800 (PST)
Received: by lbvn10 with SMTP id n10so27569589lbv.6 for ; Tue, 24 Feb 2015 12:21:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1vfJouLXMM3DlFk7FRa/GEoVo95ojuDLRdTjxn8PDj4=; b=Ks55Iz++NUpCeu9AWoPrHSWSnN1pKBNiH0tDd5KrsCRF5nJSRnoYrxyovWlDcFcio4 NynFcG00tP+XNT81Vl6I4P3l7GQUzKN770R3jGdx+cPpyjd2Hqrog6/MAi23CG1KEqG3 ftLkXCn74AL2ZTK5Kkhe4aBFpmdR7U6IVls3FsxPc6XN9Zyc/RkjiqlD8G656xm6b3yI Y+T3Ltjm03Bp7A30WuIgSjNA8DZAJpyN5O+SsrbJ8XcCX5MUJZf7XmmzfQrxBn3Fb1VK 10/Pc0bmJ/toFQP6gh77OLcut/TpchCBTEGnkaEWPwdG2OgRFXymrIoDb1xREEfBBA2o aILQ==
X-Gm-Message-State: ALoCoQlQHlUBAWXIlAygOyUpaaFtEF7vcrNNgS4zIXjsCWAm49zvJwCLY+Nb90OmZZtruBKniO+0
MIME-Version: 1.0
X-Received: by 10.152.207.37 with SMTP id lt5mr15979183lac.38.1424809289972; Tue, 24 Feb 2015 12:21:29 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Tue, 24 Feb 2015 12:21:29 -0800 (PST)
In-Reply-To: 
References:  
Date: Tue, 24 Feb 2015 12:21:29 -0800
Message-ID: 
From: Andy Bierman 
To: Kent Watsen 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] 3 new related RESTCONF/anyxml Issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Feb 2015 20:21:33 -0000

Hi,

Nobody has objected to the clarifications suggested below.
These 3 issues are now in the "verify" state.
Unless there are any objections by Saturday, February 28, 2015,
these issues will move to the "edit" state.

Andy


On Tue, Feb 17, 2015 at 1:00 PM, Kent Watsen  wrote:
>
>
>>RESTCONF #17: terminal nodes as resources
>>
>>I just noticed that the term 'data resource' in sec. 1.3.4 does not
>>include leaf-list as a node that can be a data resource.
>>The draft is mostly silent about the processing of terminal nodes as
>>data resources (except patching a leaf).
>>Details and examples for leaf-list and anyxml should be added.
>>
>>Proposed solution:
>>
>>  --> leaf-list as data resource rules TBD
>>  --> anyxml edited as a whole. Nested data nodes in anyxml mare still
>>        part of the anyxml resource, not a new sub-resource
>
> Agreed
>
>
>
>> RESTCONF #18: depth parameter and anyxml
>>
>>The depth parameter in 4.8.4 says each new child level increments
>>the depth level. The terminology mixes 'data node', 'resource',
>>and 'sub-resource'.
>>
>>Proposed solution:
>>
>>  ---> for counting nest levels, sub-resources are counted, not data
>>nodes.
>>         anyxml nodes cannot have sub-resources
>
> Agreed
>
>
>
>>RESTCONF #19: fields parameter and anyxml
>>
>>The fields parameter in 4.8.5 does not say if nested data nodes within
>>an anyxml object can be selected or not.
>>
>>Proposed solution:
>>
>>  ---> for selecting nested data nodes, anyxml is treated as a terminal
>>node
>>         so no sub-nodes within an instance can be selected with the
>>fields
>>         parameter.
>
> Agreed
>
>
>
> K.
>


From nobody Wed Feb 25 05:30:59 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A551A0451; Wed, 25 Feb 2015 05:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VixeDVdCWDZb; Wed, 25 Feb 2015 05:30:56 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3131A0406; Wed, 25 Feb 2015 05:30:56 -0800 (PST)
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: 5.11.2
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20150225133056.10361.40320.idtracker@ietfa.amsl.com>
Date: Wed, 25 Feb 2015 05:30:56 -0800
Archived-At: 
Cc: netconf@ietf.org
Subject: [Netconf] Last Call:  (Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication) to Proposed Standard
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Feb 2015 13:30:57 -0000

The IESG has received a request from the Network Configuration WG
(netconf) to consider the following document:
- 'Using the NETCONF Protocol over Transport Layer Security (TLS) with
   Mutual X.509 Authentication'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-03-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ballot/


No IPR declarations have been submitted directly on this I-D.



From nobody Thu Feb 26 06:05: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 05E8F1A0162 for ; Thu, 26 Feb 2015 06:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_pxQhj3lQpf for ; Thu, 26 Feb 2015 06:05:12 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E5D1A017F for ; Thu, 26 Feb 2015 06:04:34 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 20C4BBEB for ; Thu, 26 Feb 2015 15:04:33 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3G4ddIE8eiEv for ; Thu, 26 Feb 2015 15:04:10 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 26 Feb 2015 15:04:30 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7D7120036 for ; Thu, 26 Feb 2015 15:04:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kb9qFsNK_tFs; Thu, 26 Feb 2015 15:04:28 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ECAC320031; Thu, 26 Feb 2015 15:04:27 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id EA459324694C; Thu, 26 Feb 2015 15:04:26 +0100 (CET)
Date: Thu, 26 Feb 2015 15:04:26 +0100
From: Juergen Schoenwaelder 
To: "netconf@ietf.org" 
Message-ID: <20150226140426.GA31778@elstar.local>
Mail-Followup-To: "netconf@ietf.org" 
References:  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04
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, 26 Feb 2015 14:05:16 -0000

On Thu, Feb 05, 2015 at 01:22:43PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote:
> Dear NETCONF WG,
> we hereby issue a WG Last Call for 3 weeks for the drafts below:
> 
> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04
> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03
> 
> Please review and send your comments to the NETCONF WG mailing list by February 26, 2015 EOB PT.

Hi,

Here is my review of draft-ietf-netconf-restconf-04. Comments come
roughly in the order of the document. I am running out of time to get
a review done of draft-ietf-netconf-yang-patch-03 by today's deadline.
I may get to it by Monday (but no hard promise).

/js

- I suggest to follow RFC 6020 and use 'RPC operations' instead of
  'protocol operations' but then I note that RFC 6241 uses 'protocol
  operations'. Too bad that we are not consistent. (Should we try to
  settle on a single term? Perhaps we should fix this in YANG 1.1?)

- I suggest to use 'event notifications' instead of 'notification
  events'. The model, I think, is that event occurs that leads to a
  notification. I later parts of the document the term 'event
  notification' is actually used.

- What exactly is the 'framework' and in particular the 'meta-model'
  referred to in section 1.1? I do not understand the 'instead' -
  instead of what?

- The document talks about API resources pretty early but it is
  somewhat unclear what API resources are. Even section 3.3 is leaving
  me as an almost first time reader somewhat confused. Why is this
  thing called an API resource? Section 3.3 makes me believe this is
  simply a top-level container for data and operations (not sure where
  the other resources hang in the URI space or why they are not API
  resources).

- What does it meant that "configuration persistence are handled by
  the server and not controlled by the client." Is this trying to tell
  me that the client has no way of knowing whether any config changes
  persist? If so, is this useful? Or is the idea that all edits will
  eventually persist but not necessarily immediately, which seems to
  be what the last paragraph in 3.4 hints at. I am also unsure what
  this means: "There is no guarantee [...] that the saved
  configuration is always a mirror of the NETCONF running datastore,
  if the server also supports NETCONF." What is a NETCONF/RESTCONF
  server that supports #startup doing if edits are received via both
  NETCONF and RESTCONF? Perhaps there is a need to factor all this out
  into a separate section discussing NETCONF/RESTCONF coexistence. I
  think there are additional things to discuss, e.g. that a combined
  server also MUST maintain NETCONF last change time stamps, no?

- It often reads as if there can be multiple datastore resources but
  then at other places it seems there is only one datastore resource,
  namely {+restconf}/data. (I am wondering why this is actually a good
  idea, why do we not have {+restconf}/running plus optionally
  {+restconf}/startup? I can understand why exposing candidate may not
  be useful, but saying there is {+restconf}/data and it magically
  interacts with NETCONF's running and startup datastores makes it
  difficult for me to understand what is going on. If the goal is to
  not expose startup, then why not {+restconf}/running? How does
  {+restconf}/data different from NETCONF's running?

- I am not sure I fully understand how key values are encoded in
  corner cases where the value includes characters that conflict with
  the format. What exactly is 'a quoted or unquoted empty string'?
  Which quoting rules apply? And is the syntax defined in section
  3.5.1 the syntax before or after URI pct-encoding? I guess this is
  before pct-encoding, no? I think this encoding needs additional
  clarification and perhaps some examples showing how clashes are
  handled.

- It seems section 3.6 says operation resources only need a module
  name if the server supports operations with conflicting names. I
  think this makes interoperability actually more complex. I would
  prefer is both top-level data resources as well as operations
  resources require to use a module name.

- In section 3.6, why is sending a body a MAY if the "rpc" statement
  defines either input or output? Should this not be a MUST?

- Since XML is the default to implement encoding, would it make sense
  to show the examples in XML instead of JSON? Or show them in both
  encodings? (A few examples, e.g. section 4.6, do show both.)

- Perhaps add 'module example-ops { ... }' around the examples in
  sections 3.6.1 and 3.6.2 so that it is clear where example-ops is
  coming from.

- The example insection 3.7 seems to use the data model defined in
  draft-ietf-netconf-yang-library-00.txt. I think there should be an
  explicit reference to it (and this needs to be consistent with the
  above mentioned I-D).

- Section 4.5 says that data resources can be created using PUT, which
  is slightly at odds with Table 1.

- Section 4.2 and following sections refer to an "entry point
  component". Is this the same as "entry point" or something
  different? I am not sure what it is. Should this term be defined in
  the terminology or can we replace it with something already defined?

- Section 4.3, when do I return 403 and when 404 or can I choose
  between these error responses as I like? This seems to also apply
  to subsequent sections.

- The line wrapping in the table in section 4.8.1 is unfortunate since
  it makes with-defaults to read as two separate entries.

- Section 4.8 is about query parameters but then it section 4.8.1 and
  subsequent sections discuss restconf capabilities that are not query
  parameters. I found this a bit confusing and perhaps the document
  structure should be changed to avoid discussing general protocol
  capabilities where a reader expects a discussion of query
  parameters. When discussing (protocol) capabilities, it may be
  useful to mention how they can be retrieved.

- In section 4.8.4, I am not sure yet how nest levels are counted. If
  I request {+restconf}/data/foo which contains the child bar, is the
  child bar at nest level 2 or 1? An explicit example might help.

- Should the "insert" and "point" parameters not be required to
  implement? If they are optional, then adding something to a list or
  leaf-list ordered by user will be impossible, no?

- For the notification examples, would it make sense to provide an
  outline of the the corresponding YANG definition, e.g,

  module example-mod {
    namespace "http://example.com/event/1.0";

    notification event {
     leaf event-class { type string; }
     container reporting-entity {
       leaf card { type string; }
     }
     leaf severity { type string; }
    }
  }

  Did I get this right? Not sure this is the best example. Perhaps we
  should consider using already RFC published data model snippets as
  examples instead of mock-up examples. Well, this already leads to
  another question. Does netconf-config-change (RFC 6470) makes sense
  for RESTCONF? If so, how to fill in the details? So perhaps these
  notifications do only apply to a NETCONF server but not to a
  RESTCONF server. So do we have similar definitions for RESTCONF?

- Looking at the tree diagram of the ietf-restconf-monitoring module,
  I was wondering whether

               +--ro encoding* [type]
                  +--ro type      string
                  +--ro events    inet:uri

   should not be better named

               +--ro access* [encoding]
                  +--ro encoding  string
                  +--ro location  inet:uri

- I am also wondering whether ietf-restconf-monitoring is really the
  right module name. It defines objects to obtain the restconf
  capabilities and to find access points for the notification streams,
  this is not exactly monitoring. Perhaps -monitoring was a not so
  good choice back then and we now stay with it for consistency...

  Anyway, should there be explicit text that restconf capabilities
  must not show up in ietf-netconf-monitoring and that the counters in
  ietf-netconf-monitoring will not be bumped by restconf interactions?
  Perhaps this also belongs into a section discussing NETCONF/RESTCONF
  coexistance issues, see above.

- Section 10 normatively depends on draft-ietf-netconf-yang-library
  (as correctly stated in 14.1 - there are acutally quite a few things
  that we need to finish up in order to publish this document). I am
  not sure, though, that [rest-dissertation] really is
  normative. [XPATH] on the other hand seems to be normative rather
  than informative (see the filter option).

- Several TBD in 11.3 probably need to be filled in.

- For creating a RESTCONF Capability Registry (section 11.4), it will
  be necessary to specify the rules IANA should use to handle the
  registry.

- In section 12, I do not understand what is meant with this:

      Implementors SHOULD provide a comprehensive
      authorization scheme with RESTCONF and ensure that the resulting
      NETCONF username is made available to the RESTCONF server.

  Is this authorization or authentication? And what does
  "comprehensive" translate to?

  What does "SHOULD be implemented carefully with adequate attention
  to all manner of attack one might expect to experience with other
  management interfaces." mean? Do you mean 'implemented' or
  'deployed'?

- In the jukebox YANG module (I understand it is only an example), I
  am somewhat concerned to see rc:data-resource-identifier. This kind
  of sends the signal that it is OK to write RESTCONF specific YANG
  data models. Frankly, if the end result is that we get RESTCONF and
  NETCONF specific data models, then perhaps we should not even do
  RESTCONF in the first place. I do understand the value of having a
  REST interface but I am also very much concerned if data models
  become either NETCONF or RESTCONF specific.

- I have not reviewed the examples in appendix D.

/js

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


From nobody Thu Feb 26 09:04:53 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126A71A87E6 for ; Thu, 26 Feb 2015 09:04:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDYijUlTtvWm for ; Thu, 26 Feb 2015 09:04:47 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8077F1A90EB for ; Thu, 26 Feb 2015 09:04:02 -0800 (PST)
Received: from localhost (host-78-79-162-173.mobileonline.telia.com [78.79.162.173]) by mail.tail-f.com (Postfix) with ESMTPSA id 5D3941280A55; Thu, 26 Feb 2015 18:04:01 +0100 (CET)
Date: Thu, 26 Feb 2015 18:04:00 +0100 (CET)
Message-Id: <20150226.180400.1762013018376155853.mbj@tail-f.com>
To: mehmet.ersue@nsn.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] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Feb 2015 17:04:52 -0000

"Ersue, Mehmet (NSN - DE/Munich)"  wrote:
> Dear NETCONF WG,
> we hereby issue a WG Last Call for 3 weeks for the drafts below:
> 
> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04
> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03

I have mentioned this before, but I don't think it has been resolved
yet - the usage of anyxml in the patch document needs more work.
Together with the latest json draft, the anyxml usage is
underspecified, and will not be interoperable.


/martin