From owner-netconf@ops.ietf.org Sat Mar 1 09:57:22 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5BF3A6D1A for ; Sat, 1 Mar 2008 09:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGHn70qojE9Z for ; Sat, 1 Mar 2008 09:57:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 478F43A6F8B for ; Sat, 1 Mar 2008 09:57:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVVnN-0002S3-71 for netconf-data@psg.com; Sat, 01 Mar 2008 17:46:49 +0000 Received: from [76.96.30.56] (helo=QMTA06.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVVnK-0002Rg-N3 for netconf@ops.ietf.org; Sat, 01 Mar 2008 17:46:48 +0000 Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id vquh1Y0180lTkoCA60BV00; Sat, 01 Mar 2008 17:46:13 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id vtmc1Y00E4HwxpC8Q00000; Sat, 01 Mar 2008 17:46:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=CuxpzXyQMEMA:10 a=qcBi1L2NWJTITRVAbfoA:9 a=nCiKy10AFjtTREPClhaFBlbjGsQA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'Andy Bierman'" , "'Phil Shafer'" Cc: "'Mehmet Ersue'" , , "'Bert Wijnen'" , "'Dan Romascanu'" References: <200802292012.m1TKC2Hl058861@idle.juniper.net> <47C89092.6000606@andybierman.com> Subject: RE: Agenda for NETCONF WG session at IETF #71 Date: Sat, 1 Mar 2008 12:46:36 -0500 Message-ID: <0bd401c87bc4$341f1d80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach7KMe8YSRbfOiyTn2U7RJCucH/+gAmuXyQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <47C89092.6000606@andybierman.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk > My top 3 issues (also nowhere on the radar): > > 1) A NETCONF DML for non-modeling-experts, so operators, engineers, > and IETFers can use NETCONF with ease > 2) An access control model > 3) A robust, extensible, multi-protocol NM architecture, that pulls > together NETCONF, CLI, SNMP, SYSLOG, existing MIBs, new > next-gen MIBs, > into a secure and standard API framework. > +1 Instead of the train, I'd be really happy if 1 and 2 were compatible with 3. ;-) David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Mar 2 03:25:50 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD97F3A68E5 for ; Sun, 2 Mar 2008 03:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPQXoRJoVNWg for ; Sun, 2 Mar 2008 03:25:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4B613A6DC4 for ; Sun, 2 Mar 2008 03:23:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVm8s-000Hni-Oo for netconf-data@psg.com; Sun, 02 Mar 2008 11:14:06 +0000 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVm8p-000Hmh-DW for netconf@ops.ietf.org; Sun, 02 Mar 2008 11:14:05 +0000 X-IronPort-AV: E=Sophos;i="4.25,434,1199682000"; d="scan'208";a="95169335" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Mar 2008 06:13:59 -0500 X-IronPort-AV: E=Sophos;i="4.25,434,1199682000"; d="scan'208";a="162556130" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Mar 2008 06:13:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Agenda for NETCONF WG session at IETF #71 Date: Sun, 2 Mar 2008 12:13:56 +0100 Message-ID: In-Reply-To: <0bd401c87bc4$341f1d80$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach7KMe8YSRbfOiyTn2U7RJCucH/+gAmuXyQACR/KYA= References: <200802292012.m1TKC2Hl058861@idle.juniper.net> <47C89092.6000606@andybierman.com> <0bd401c87bc4$341f1d80$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David B Harrington" , "Andy Bierman" , "Phil Shafer" Cc: "Mehmet Ersue" , , "Bert Wijnen" Sender: owner-netconf@ops.ietf.org Precedence: bulk =20 > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net]=20 > Sent: Saturday, March 01, 2008 7:47 PM > To: 'Andy Bierman'; 'Phil Shafer' > Cc: 'Mehmet Ersue'; netconf@ops.ietf.org; 'Bert Wijnen';=20 > Romascanu, Dan (Dan) > Subject: RE: Agenda for NETCONF WG session at IETF #71 >=20 >=20 > =20 >=20 > =20 > > My top 3 issues (also nowhere on the radar): > >=20 > > 1) A NETCONF DML for non-modeling-experts, so operators, > engineers, > > and IETFers can use NETCONF with ease > > 2) An access control model > > 3) A robust, extensible, multi-protocol NM architecture, that > pulls > > together NETCONF, CLI, SNMP, SYSLOG, existing MIBs,=20 > new next-gen=20 > > MIBs, > > into a secure and standard API framework. > >=20 >=20 > +1 >=20 > Instead of the train, I'd be really happy if 1 and 2 were=20 > compatible with 3. ;-) >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com >=20 Speaking as a contributor:=20 +1 Speaking as an AD:=20 1) we are working on it, and if we can reach consensus in Philadelphia we should have it chartered sometimes soon 2) It looks to me that the community did not reach consensus that this is an urgent item when the discussions for NETCONF rechartering happened 3) It was one of my big items when I became an AD two years ago. It still is now. The scope is beyond NETCONF, so this should be discussed in the OPS Area.=20 Dan -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Mar 2 03:57:10 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE5C3A67FB for ; Sun, 2 Mar 2008 03:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=1.403, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-O4CiU4aP3j for ; Sun, 2 Mar 2008 03:57:05 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4C103A6781 for ; Sun, 2 Mar 2008 03:57:04 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVmh0-000Pn9-Dn for netconf-data@psg.com; Sun, 02 Mar 2008 11:49:22 +0000 Received: from [217.115.75.233] (helo=demumfd001.nsn-inter.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVmgx-000PlW-NM for netconf@ops.ietf.org; Sun, 02 Mar 2008 11:49:21 +0000 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m22BnAi9030832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Mar 2008 12:49:10 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m22Bn6LJ014747; Sun, 2 Mar 2008 12:49:09 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Mar 2008 12:49:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Agenda for NETCONF WG session at IETF #71 Date: Sun, 2 Mar 2008 12:49:06 +0100 Message-ID: In-Reply-To: <200802292012.m1TKC2Hl058861@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach7EOBUYfAHkYIuQFKpcnYCzDAmyQAu3ZkA References: <47C84576.7020206@andybierman.com> <200802292012.m1TKC2Hl058861@idle.juniper.net> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Phil Shafer" , "Andy Bierman" Cc: , "ext Bert Wijnen - IETF" , "ext Romascanu, Dan (Dan)" X-OriginalArrivalTime: 02 Mar 2008 11:49:06.0562 (UTC) FILETIME=[6B63A620:01C87C5B] Sender: owner-netconf@ops.ietf.org Precedence: bulk Phil Shafer wrote: > - Why aren't/won't application writers moving to NETCONF? > - Why isn't NETCONF becoming the answer to configuration problems? > - What's stopping it? concerning the long wish list I would rather focus on what NETCONF=20 WG can do.=20 What NETCONF WG could do is e.g. to prepare a NETCONF BCP=20 document and provide interoperability reports. IMO this would=20 increase the level of awareness in the industry and enable also=20 NETCONF-ignorants to try it. We need to show it is easy to=20 deploy and cost efficient. David Harrington wrote: > > My top 3 issues (also nowhere on the radar): > >=20 > > 1) A NETCONF DML for non-modeling-experts, so operators, engineers, > > and IETFers can use NETCONF with ease > > 2) An access control model > > 3) A robust, extensible, multi-protocol NM architecture, that pulls > > together NETCONF, CLI, SNMP, SYSLOG, existing MIBs, new next-gen=20 > > MIBs, into a secure and standard API framework. 1) One big enabler for sure we have to develope is the DML. 2) This seemed not to be urgent in the WG discussion. We should=20 discuss how fast the group wants to proceed with it. However, we=20 shouldn't block people who are already busy with other work. 3) "A robust, extensible, multi-protocol NM architecture" is just what=20 want too, but I don't know how to come there. IETF usually does not=20 develop architectures OTOH we need to define the framework where=20 the (multi-)protocols have to interoperate. A vision one can have is a DML which supports the "multi-protocol NM=20 architecture". The next step would be to model the configuration data=20 for the different management layers in this architecture by designing=20 the data model with a top-down approach and by re-using already=20 available parts. Cheers,=20 Mehmet=20 =20 > -----Original Message----- > From: ext Phil Shafer [mailto:phil@juniper.net]=20 > Sent: Friday, February 29, 2008 9:12 PM > To: Andy Bierman > Cc: Ersue, Mehmet (NSN - DE/Muenich); netconf@ops.ietf.org;=20 > ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) > Subject: Re: Agenda for NETCONF WG session at IETF #71=20 >=20 > Andy Bierman writes: > >I don't think this is really fair to the new co-Chairs. >=20 > Don't mean to be unfair to anyone, I'm just looking > to see if we can get an idea of what our obstacles > are and if we know what we should be doing about them. >=20 > My top-five goes: > a) DML > b) open source toolkits in common development languages > c) evangelism/training/documentation/tutorials > d) blank > e) blanker >=20 > I'd love to know what (d) and (e) should be, but, well > I don't see it. Do folks feel that the charter items > are really seen as obstacles to using netconf? >=20 > Thanks, > Phil >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 3 05:22:11 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65C63A6810 for ; Mon, 3 Mar 2008 05:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCJFrVHxByRc for ; Mon, 3 Mar 2008 05:22:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DCD193A6A43 for ; Mon, 3 Mar 2008 05:22:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWAQc-000I8g-6r for netconf-data@psg.com; Mon, 03 Mar 2008 13:10:02 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWAQW-000I7N-53 for netconf@ops.ietf.org; Mon, 03 Mar 2008 13:09:57 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3E3E620C52; Mon, 3 Mar 2008 14:09:53 +0100 (CET) X-AuditID: c1b4fb3c-ae8bcbb000007e19-68-47cbf8a1bb95 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 26B1820C74; Mon, 3 Mar 2008 14:09:53 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Mar 2008 14:09:52 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Mar 2008 14:09:52 +0100 Message-ID: <47CBF8A0.7000406@ericsson.com> Date: Mon, 03 Mar 2008 14:09:52 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer CC: "Ersue, Mehmet (NSN - DE/Muenich)" , netconf@ops.ietf.org, ext Bert Wijnen - IETF , "ext Romascanu, Dan (Dan)" Subject: Re: Agenda for NETCONF WG session at IETF #71 References: <200802281457.m1SEv2Jh095469@idle.juniper.net> In-Reply-To: <200802281457.m1SEv2Jh095469@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2008 13:09:52.0495 (UTC) FILETIME=[DE3417F0:01C87D2F] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk My Netconf wish-list) 1) Decision on the basis of the DML: YANG, DSDL, XSD, ELUA, ... 2) All the DML details Please!!! Please !!! Please !!! And after that: 3) Actions/Custom RPCs 4) Freeware Netconf implementations 5) Some basic data models (Discovery, Something like the MIB-2 System group, Monitoring) 6) Partial Locking Balazs Phil Shafer wrote: > "Ersue, Mehmet (NSN - DE/Muenich)" writes: >> Please let us also know whether you have a concrete topic for >> the open mic session. > > I posted a list of question for discussion at the last ietf, > but nothing really came of it. Is it worth repeating? > >> Another thought is to come up with a list of the five biggest >> impediments to NETCONF's complete domination of the configuration >> space. Do we know the answers to questions like: >> >> - Why aren't/won't device folks shipping netconf implementations? >> - Why aren't/won't application writers moving to NETCONF? >> - Why isn't NETCONF becoming the answer to configuration problems? >> - What's stopping it? >> - Where's the chicken? >> - What's the egg? >> - What's the key to moving forward from here? >> - Where should we be concentrating our (precious and few) resources? > > The first issue (YANG) is clearly the (YANG) lack of a workable > DML, and (YANG) I think we are making (YANG) great progress > in that (YANG) area. > > But I don't know what the other four top-five issues are. What > stands between us and Complete World Domination (CWD)? > > Thanks, > Phil (the (YANG) subtle one ;^) > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 3 05:36:19 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D463A6945 for ; Mon, 3 Mar 2008 05:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBUBb0gs4WzZ for ; Mon, 3 Mar 2008 05:36:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 161EA3A6A13 for ; Mon, 3 Mar 2008 05:36:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWAi2-000Kga-EC for netconf-data@psg.com; Mon, 03 Mar 2008 13:28:02 +0000 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWAhp-000KeM-3k for netconf@ops.ietf.org; Mon, 03 Mar 2008 13:27:57 +0000 X-IronPort-AV: E=Sophos;i="4.25,438,1199682000"; d="scan'208";a="95331588" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Mar 2008 08:27:40 -0500 X-IronPort-AV: E=Sophos;i="4.25,438,1199682000"; d="scan'208";a="162941486" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Mar 2008 08:27:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Agenda for NETCONF WG session at IETF #71 Date: Mon, 3 Mar 2008 14:27:37 +0100 Message-ID: In-Reply-To: <47CBF8A0.7000406@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach9L+7YfIfzxJbaQCWTmMnv6MshzwAAfpOA References: <200802281457.m1SEv2Jh095469@idle.juniper.net> <47CBF8A0.7000406@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Balazs Lengyel" , "Phil Shafer" Cc: "Ersue, Mehmet (NSN - DE/Muenich)" , , "ext Bert Wijnen - IETF" Sender: owner-netconf@ops.ietf.org Precedence: bulk I need to draw everybody's attention (including mine :-)) that the focus of the NETCONF WG activity should be on the items the NETCONF WG is currently chartered for. Those should have meeting time priority. Other subjects may be discussed if time is left.=20 Dan > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]=20 > Sent: Monday, March 03, 2008 3:10 PM > To: Phil Shafer > Cc: Ersue, Mehmet (NSN - DE/Muenich); netconf@ops.ietf.org;=20 > ext Bert Wijnen - IETF; Romascanu, Dan (Dan) > Subject: Re: Agenda for NETCONF WG session at IETF #71 >=20 > My Netconf wish-list) > 1) Decision on the basis of the DML: YANG, DSDL, XSD, ELUA, ... > 2) All the DML details >=20 > Please!!! Please !!! Please !!! >=20 > And after that: >=20 > 3) Actions/Custom RPCs > 4) Freeware Netconf implementations > 5) Some basic data models (Discovery, Something like the=20 > MIB-2 System group, Monitoring) > 6) Partial Locking >=20 > Balazs >=20 > Phil Shafer wrote: > > "Ersue, Mehmet (NSN - DE/Muenich)" writes: > >> Please let us also know whether you have a concrete topic for the=20 > >> open mic session. > >=20 > > I posted a list of question for discussion at the last ietf, but=20 > > nothing really came of it. Is it worth repeating? > >=20 > >> Another thought is to come up with a list of the five biggest=20 > >> impediments to NETCONF's complete domination of the configuration=20 > >> space. Do we know the answers to questions like: > >> > >> - Why aren't/won't device folks shipping netconf implementations? > >> - Why aren't/won't application writers moving to NETCONF? > >> - Why isn't NETCONF becoming the answer to configuration problems? > >> - What's stopping it? > >> - Where's the chicken? > >> - What's the egg? > >> - What's the key to moving forward from here? > >> - Where should we be concentrating our (precious and few)=20 > resources? > >=20 > > The first issue (YANG) is clearly the (YANG) lack of a=20 > workable DML,=20 > > and (YANG) I think we are making (YANG) great progress in=20 > that (YANG)=20 > > area. > >=20 > > But I don't know what the other four top-five issues are. =20 > What stands=20 > > between us and Complete World Domination (CWD)? > >=20 > > Thanks, > > Phil (the (YANG) subtle one ;^) > >=20 > > -- > > to unsubscribe send a message to=20 > netconf-request@ops.ietf.org with the=20 > > word 'unsubscribe' in a single line as the message text body. > > archive: >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 3 05:40:40 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38783A6FBE for ; Mon, 3 Mar 2008 05:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.142 X-Spam-Level: X-Spam-Status: No, score=-1.142 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi9RlMwZHOkc for ; Mon, 3 Mar 2008 05:40:39 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 817A828C622 for ; Mon, 3 Mar 2008 05:39:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWAlS-000LFu-Bt for netconf-data@psg.com; Mon, 03 Mar 2008 13:31:34 +0000 Received: from [217.115.75.234] (helo=demumfd002.nsn-inter.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWAlJ-000LEa-7Z for netconf@ops.ietf.org; Mon, 03 Mar 2008 13:31:29 +0000 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m23DVGQO030967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 14:31:16 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m23DVCTr009606; Mon, 3 Mar 2008 14:31:12 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Mar 2008 14:31:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Agenda for NETCONF WG session at IETF #71 Date: Mon, 3 Mar 2008 14:31:11 +0100 Message-ID: In-Reply-To: <47CBF8A0.7000406@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach9L+F/yCUl60M1T6GVFOhuBqIErAAAEASg References: <200802281457.m1SEv2Jh095469@idle.juniper.net> <47CBF8A0.7000406@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Balazs Lengyel" , "Phil Shafer" Cc: , "ext Bert Wijnen - IETF" , "ext Romascanu, Dan (Dan)" X-OriginalArrivalTime: 03 Mar 2008 13:31:12.0071 (UTC) FILETIME=[D8E3E570:01C87D32] Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Balazs, let us focus in the open mic slot (if we have time for it) on topics=20 where NETCONF WG can do something. We think it is interesting to discuss NETCONF-related requirements=20 on DML as a preparation for the CANMOD BoF.=20 But overall RCDML requirements and DML solution discussion will be=20 excluded. I guess, any decisions on the future DML work will be taken in=20 CANMOD BoF. Cheers,=20 Mehmet=20 =20 > -----Original Message----- > From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]=20 > Sent: Monday, March 03, 2008 2:10 PM > To: Phil Shafer > Cc: Ersue, Mehmet (NSN - DE/Muenich); netconf@ops.ietf.org;=20 > ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) > Subject: Re: Agenda for NETCONF WG session at IETF #71 >=20 > My Netconf wish-list) > 1) Decision on the basis of the DML: YANG, DSDL, XSD, ELUA, ... > 2) All the DML details >=20 > Please!!! Please !!! Please !!! >=20 > And after that: >=20 > 3) Actions/Custom RPCs > 4) Freeware Netconf implementations > 5) Some basic data models (Discovery, Something like the=20 > MIB-2 System group, Monitoring) > 6) Partial Locking >=20 > Balazs >=20 > Phil Shafer wrote: > > "Ersue, Mehmet (NSN - DE/Muenich)" writes: > >> Please let us also know whether you have a concrete topic for > >> the open mic session. > >=20 > > I posted a list of question for discussion at the last ietf, > > but nothing really came of it. Is it worth repeating? > >=20 > >> Another thought is to come up with a list of the five biggest > >> impediments to NETCONF's complete domination of the configuration > >> space. Do we know the answers to questions like: > >> > >> - Why aren't/won't device folks shipping netconf implementations? > >> - Why aren't/won't application writers moving to NETCONF? > >> - Why isn't NETCONF becoming the answer to configuration problems? > >> - What's stopping it? > >> - Where's the chicken? > >> - What's the egg? > >> - What's the key to moving forward from here? > >> - Where should we be concentrating our (precious and few)=20 > resources? > >=20 > > The first issue (YANG) is clearly the (YANG) lack of a workable > > DML, and (YANG) I think we are making (YANG) great progress > > in that (YANG) area. > >=20 > > But I don't know what the other four top-five issues are. What > > stands between us and Complete World Domination (CWD)? > >=20 > > Thanks, > > Phil (the (YANG) subtle one ;^) > >=20 > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 3 13:20:36 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293B928C2DD for ; Mon, 3 Mar 2008 13:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kogNqsflahIe for ; Mon, 3 Mar 2008 13:20:29 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8AF683A68FD for ; Mon, 3 Mar 2008 13:19:26 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWHwa-000HXY-I7 for netconf-data@psg.com; Mon, 03 Mar 2008 21:11:32 +0000 Received: from [76.96.62.24] (helo=QMTA02.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWHwX-000HWv-NN for netconf@ops.ietf.org; Mon, 03 Mar 2008 21:11:31 +0000 Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA02.westchester.pa.mail.comcast.net with comcast id iiTX1Y00F1HzFnQ050Ef00; Mon, 28 Jan 2008 22:47:57 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.westchester.pa.mail.comcast.net with comcast id imns1Y00G4HwxpC3a00000; Mon, 28 Jan 2008 22:47:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=Np8W4u-N0-mgJplV7rwA:9 a=I-bH-MM_WT4hC_E-xs9uuICFTA0A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=t6y72FoqvCQA:10 a=UzCga9AbxpcA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen'" , "'Netconf'" References: Subject: RE: review of draft-ietf-netconf-monitoring-00.txt Date: Mon, 28 Jan 2008 17:47:52 -0500 Message-ID: <026c01c861ff$d13511d0$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AchhumByj2VpCbGAQmC4dWqlTmEF6AAREPDA In-Reply-To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, > - By the way, I personally like citations of the form [RFC4741] better > than of the form [NETCONF], because that way I can quicker > pick up the > referenced RFC. Best I think would be to change > > [NETCONF] can be ... > > into > > NETCONF [RFC4741] can be.... > Personally I prefer [NETCONF] to [RFC4741] because I can see without interrupting my reading what content is being referenced rather than what RFC. With [RFC4741] I need to stop reading to go look in the References section to figure out what [RFC4741] refers to. It also has the benefit of being able to be updated in the References section (esp. for I-Ds) without impacting what is in the text sections. I also find documents named rfcXXXXbis to be poorly named because I have to go lookup rfcXXXX to know what is being updated by the bis. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 4 00:44:01 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF4F28C168 for ; Tue, 4 Mar 2008 00:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecYxAxFt1+Et for ; Tue, 4 Mar 2008 00:43:54 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 58C163A6890 for ; Tue, 4 Mar 2008 00:43:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWScb-0006Rd-Ac for netconf-data@psg.com; Tue, 04 Mar 2008 08:35:37 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWScX-0006PL-Eb for netconf@ops.ietf.org; Tue, 04 Mar 2008 08:35:35 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9488921474; Tue, 4 Mar 2008 09:34:29 +0100 (CET) X-AuditID: c1b4fb3e-a99fdbb000000b15-bc-47cd09957f32 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7E66821556; Tue, 4 Mar 2008 09:34:29 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 09:34:29 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 09:34:28 +0100 Message-ID: <47CD0994.7080801@ericsson.com> Date: Tue, 04 Mar 2008 09:34:28 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Harrington CC: netconf@ops.ietf.org Subject: Re: review of partial-lock-01 References: <0bc101c87b2c$12eb7f20$0600a8c0@china.huawei.com> In-Reply-To: <0bc101c87b2c$12eb7f20$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2008 08:34:28.0972 (UTC) FILETIME=[8FD452C0:01C87DD2] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Hello Dave, Thanks for your comments. I answered a number of them. I will continue later. Balazs David Harrington wrote: > Hi, > > section 2.1. > paragraph 2 - I think this should start "The system MUST ensure". You > will have interoperability problems if everybody doesn't follow the > same rules on this. OK wording will be changed > > paragraph 4 - "one or more datastores" This is the first mention of > multiple datastores in this document, and I think it would be good to > make sure readers know you are referring to running, startup, > candidate, etc. I can think of other types of datastores, such as the > datastores for blade 1 and for blade 2 in a chassis, and it is > important that standards are clear and unambiguous. The global lock > seems to only work on one target datastore per command. OK > > paragraph 4 - if the XPath will be applied to multiple datastores, > must the datastores be in the same naming space? Can XPath span > multiple datastores in different naming spaces? Only one datastore can be modified with one operation. The datastore is specified with a separate element, it is not part of the XPATH expression. I will try to clarify this better. > > section 2.2 This and elsewhere in the document needs to be tightened > by using the RFC2119 language to promote interoperability between > multiple clients and multiple servers. "Partial locking uses only > restricted XPath to describe the lock's scope ... [and] optionally can > utilize any XPath ...". Well, which is the base standard that is > mandatory to implement to claim compliance to this spec? OK > > The support for a full XPath expression is not necessarily > interoperable, and it should probably be moved to a different > paragraph, identified as an optional extension to the standard, and > contain discussion of the problems one should expect if a client tries > to rely on full XPath support in the servers. I don't really understand the comment. > > section 2.4.1 - the security considerations section should have > discussion of how doing the evaluation only once can have security > implications. I recommend that such discussion include an example of > how a data model to configure a security protocol might be impacted > (or not). What issues do you have in mind? > > The bullet on access rights says if the user must have "at least some > basic access rights, e.g., read rights, ...", but later you say "when > a partial lock is executed you get what you asked for: a set of nodes > that are locked for writing." So shouldn't the "at least basic access > rights" be authorization to write the data? And, again, this should > probably be converted to RFC2119 language. We cant assume anything about what kind of access control the device has. The only thing we can say is that: If there is access control, it defines some rights; we know nothing about what kind of rights that means. Maybe just access/no-access. So I will rather modify the second section: "when a partial lock is executed you get what you asked for: a set of nodes that are protected from modification." > > "There are some other issues that are intentionally not addressed for > the sake of simplicity." Since you know some issues are not addressed, > then some issues must have already been identified. What are those > known issues that are not addressed? Wrong wording. The following bullets contain the issues that were considered. It should be: "For the sake of simplicity the following was decided:" (not the best wording :-) Help! > > (By this time, I wish you had more subsections, so it was easier for > me to identify where I am in the text for you.) OK, will try to do something. > > s/does not effect/does not affect/ OK > > "An operator is allowed to edit the configuration both inside and > outside the scope of a lock." Can you give an example to show why this > is part of the proposed design? Some people were concerned what happens if you lock e.g. the interfaces only, then you realize that you must edit the access control lists as well? Can you do it ? Is it not a risk to lock just part of the data ? The answer is, yes you can edit outside the lock, but you should lock everything you really need, otherwise there is a risk of inconsistency. > > " Note: The operation does not modify the global > > operation defined in the base NETCONF Protocol [RFC4741]. If part > of > a datastore is already locked by , then a global lock > for that datastore fails even if the global lock is attempted by > the > same NETCONF session which owns the partial-lock." > Will a global unlock command unlock one or more partial locks? No. It is not possible to have both partial and global locks at the same time. Whichever lock is attempted later (global or partial) will fail. > > "The select expressions MUST return a node set." I suggest adding ", > which MAY be empty." No this should be an error, see section negative results. > > s/instances.]/instances./ OK > > "If any select expression returns anything but a node set, the > shall be 'invalid-value'." Since it is non-compliant to > return anything other than a node set, what makes you think the > non-compliant implementation will return the correct error-tag? The reason of the problem is that the manager/client sent a non-compliant XPath, so the netconf agent/server should still work properly. > > "invalid value" is returned for both (not a node set) and (:xpath not > supported). Shouldn't these be different error codes? The non-node-set > is always invalid, but the lack of :xpath is not invalid. What would you propose? We can specify an error-app-tag "XPath does not return a nodeset" ":xpath capability not supported" > > section 3 Security Considerations is inadequate. There are potential > security vulnerabilities caused by partial locking that are not > described in the netconf base protocol. What vulnerabilities are you thinking of? > > To make things easier for IANA, the IANA Considerations should point > to the existing IANA registry > http://www.iana.org/assignments/netconf-capability-urns and how it > should be changed rather than making them look up this information in > the Netconf RFC. OK > > I recommend making the Open Issues a separate section from the Change > Log. OK > > If we do not allow lock multiple datastores in one operation, maybe we > should recommend locking them in a particular order, which could help > prevent deadlocks. Good idea (although this was not done for global locking). > > I recommend showing the latest changes first. That's fairly typical in > my experience. OK > > Appendix B - I have a real issue with using a DML to define new > operations. The IETF Management Framework has deliberate;y kept > protocol definitions and data model definitions separate for fifteen > years, and I don't think the Netconf WG alone can reverse that design > decision. That level of change should be discussed before the whole > IETF. In addition, this violates the architectural layering in the > Netconf architecture, which separates content and RPCs (operations). The notification draft already describes both data and operations (protocol). I think it is a basic idea in NETCONF that some things can be changed/configured with basic get/edit-config operations while for some we will make custom RPCs/operations/actions. > > s/modul/module/ OK > > The YANG spec doesn't identify which version of YANG is used. This > info is available in an SMIvx MIB module or an XSD schema. In YANG version 1 is default. If anything else would be used that would be stated. > > Does the revision clause refer to urn:...:partial-lock:1.0? What if > these get out of sync? By definition all revision statements are valid for this module and the urn defined here, so they can not get out of sync. However YANG versioning rules (as YANG itself are not finalized. > > Appendix C. > Should the XSD include organization amnd contact? > It would probably be good to annotate the fact that "nc:config-name" > provides a choice. OK > > > Do operators need to take the same desired configuration and have a > version of their XML (or YANG or ...) configuration document that only > supports the base protocol, another that supports partial locking > without :xpath, and a third that supports :partial-locking with > :xpath? Or should they write their configuration using conditional > language constructs? No why would they? It was agreed as a DML requiremetn that the DML must support partial locking. > > I can see complexity in supporting multiple versions for partial > locking. What happens to an operator's configuration designs when > there are a lot more capabilities, each with their own optional > extensions or combinations of capabilities, like here? Can we reduce > the number of options in the partial-locking proposal? I don't see the need for multiple versions. > > Operational considerations might also address how partial locking will > affect other services in the network. Netconf locking (both global and > partial) is creating new requirements for SNMP, CLI, and other > protocols. The impact on other NM protocols should be documented. Are there any new impacts compared to global-locking? Generally the only capability needed is that all protocols must be able to refuse an operation, however that must already be implemented as there are many other reasons to refuse an operations: access control, unavailable system resources, etc. IMHO how the lock and it's scope is registered internally is an implementation issue. > > SNMP response times may get worse if partial locking prevents SNMP > from performing a SET to an object. A Netconf lock might prevent an > existing SNMP application that is used to "tweak" a system's > configuration to maintain or improve performance or correct for a > detected fault may not work as quickly if there are Netconf locks in > place. in fact, an operator may not be able to fix a time-critical > problem via SNMP or CLI. This impact should be spelled out in the > document. If something is locked that the SNMP application wants to change then the SNMP application will not slow down, it will fail. And that is what we want. It is stated that the system will prevent modification by other interfaces, protocols. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 4 05:25:24 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE883A67E1 for ; Tue, 4 Mar 2008 05:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLyU0k7rW15Y for ; Tue, 4 Mar 2008 05:25:10 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B3F23A6AD5 for ; Tue, 4 Mar 2008 05:25:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWWxs-000Lc8-04 for netconf-data@psg.com; Tue, 04 Mar 2008 13:13:52 +0000 Received: from [217.115.75.234] (helo=demumfd002.nsn-inter.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWWxe-000Lap-UT for netconf@ops.ietf.org; Tue, 04 Mar 2008 13:13:47 +0000 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m24DDYSE030219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 14:13:34 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m24DDYfh025161; Tue, 4 Mar 2008 14:13:34 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Mar 2008 14:13:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87DF9.8C698464" Subject: Review of the draft-ietf-netconf-partial-lock-01 Date: Tue, 4 Mar 2008 14:13:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of the draft-ietf-netconf-partial-lock-01 Thread-Index: Ach9+YzK6Kxqm5VZR/ezWFnUrr1I0w== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Balazs Lengyel" Cc: , "ext Bert Wijnen - IETF" X-OriginalArrivalTime: 04 Mar 2008 13:13:34.0451 (UTC) FILETIME=[8CE9A430:01C87DF9] Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C87DF9.8C698464 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Balazs, I reviewed the -01 version of the draft "Partial Lock RPC for NETCONF".=20 In general the draft looks good but needs some improvements. Please find below my comments: Section 2.1., paragraph 2: as David H. states please use explicit wording from RFC 2119: "MUST ensure" instead of "ensures"=20 s/be// Section 2.1., paragraph 3: Would change for more clarity: "The partial lock operation starts when the partial lock is granted=20 and lasts until either the corresponding operation=20 succeeds or the NETCONF session terminates." Section 2.2.: Please use MUST or SHOULD to indicate what needs to be supported=20 as a minimum and what can be supported additionally. Section 2.4.1., paragraph 4: I was wondering whether we need more explanation of the atomic=20 operation. I would suggest to extend the text with following for clarity even if it looks redundant: "I.e., the server MUST ensure to unlock all already locked parts if one=20 of the requested parts cannot be locked." Section 2.4.1., paragraph 7, bullet 2: The conclusion of the discussion last December was that we don't=20 want to change Netconf RFC chapter 7.5, which says: "An attempt to lock the configuration MUST fail if an existing session=20 or other entity holds a lock on any portion of the lock target." The wording "another management sesion" implies excluding the current session. Based on the conclusion of our discussion, "overlapping partial locks by the=20 same session are not allowed", I would suggest to change 2nd bullet to: o Any part of the scope to be locked is already locked by any management session/protocol, including the current session and=20 other NETCONF sessions using the or any other=20 non-NETCONF management method. Section 2.4.1., paragraph 7, bullet 3: IMO "at least some basic access rights" is too vague. We need to state explicitely which access rights are necessary. I assume the reason why a session uses partial-lock is to be able to write in an atomic way (this is at least mentioned in Section 2.4.1., paragraph 9).=20 So, why is it sufficient to have "read rights"? Was the intention here to prevent=20 others from writing? Section 2.4.1., paragraph 8: I would like to suggest to use more explicite wording. I assume you mean "sessions" if you say "users" and "different locking scopes"=20 if you say "different parts". My question is: How is it possible that two sessions trying to lock "different=20 parts" get dead-locked? IMO the dead-lock happens only if session A and=20 session B try to lock the "same locking scope" and session A does not free=20 the partial-lock it executed and session B waits forever. Based on the rule defined in Section 2.4.1., paragraph 4 the partial-lock=20 (of potentially many lock areas) is handled in an atomic way. So i.e.: Locking a set of "locking scopes" is a good strategy if session A doesn't=20 want to be disturbed during it's work. Locking a set of "locking scopes" at once does not help against waiting=20 of session B if something is already locked by session A. Section 2.4.1., paragraph 9: I would skip "you get what you asked for". "It is the intention to keep partial-locking simple. Partial=20 lock aims to lock a set of nodes for writing only."=20 I would like to ask the same question as David H. What are the issues=20 that are intentionally not addressed. But I see in your mail that you want=20 to s/./:/ ;-). Section 2.4.1., paragraph 9, bullet 2 and 3: 'Section 2.4.1., paragraph 8', 'Section 2.4.1., paragraph 9, bullet 2' and=20 'Section 2.4.1., 9th paragraph, bullet 3' have the same general statement=20 in mind and seem to be redundant. I would reduce some of the redundant=20 text with a clear statement: "It is the operator's responsibility to lock all parts of the=20 datastore that are crucial for a specific management action." Section 2.4.1., paragraph 10: It is interesting for clarity if you add this or exchange it with parts of the current text: "Partial and global lock follow the same rules as defined in RFC4741." Section 2.4.1., paragraph 16 (beginning with "If any select expression=20 returns anything but ..."): I don't agree with David H., if the select expression is erroneous the shall be 'invalid-value'. Also here we should use RFC 2119 wording: "SHALL" I would change the paragraph for more clarity: "If the select expression is erroneous and does not point to=20 a node set, the SHALL be 'invalid-value'. Section 3.: IMO it is important to extend this section. We should state what we mean with "some access control mechanism" at least to some extend and although we have no access control draft yet. <***> A general issue I anticipate here is that we most likely cannot get the=20 "Partial Lock" draft and also other drafts which depend on "NETCONF=20 access control mechanisms" through the IESG. I assume IESG will ask=20 for it as a companion draft and we need to provide the AC mechanism=20 in parallel. We should discuss this on the maillist and need also the advice=20 of Dan. Section 4.: Since we had some issues during the shepperding of the Notifications draft I would like to suggest to use the wording and template from the=20 Notifications draft (other useful examples are available in RFC 4825). Appendix A: I would divide it in two sub-sections or appendices: Change log, Open issues. Appendix A - Open Issues: I think we shouldn't introduce a special rule for locking non-existent nodes.=20 IMO it is better if the operator creates "empty nodes" if he wants to reserve an object or it's name/key.=20 We should include more detailed information in error results to help debug=20 lock conflicts but how detailed should this information be. If you are in=20 favor please provide a proposal and we can discuss and decide in the WG. IMO we should allow users to lock parts of multiple datastores. This is in=20 support of the "atomic lock operation" for a set of "locking scopes" at once,=20 which is useful and necessary even beyond the borders of a datastore and even the current (global) operation does not support this. Appendix B, C: I understand you would like to see YANG as the "normative DML" but we=20 need to choose one of the models in the appendices as the normative=20 reference of today. As I understood Dan correctly, currently XSD can be=20 used as a the "normative reference". Section 9.: Please add YANG draft to the list of references. Cheers,=20 Mehmet=20 ------_=_NextPart_001_01C87DF9.8C698464 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of the draft-ietf-netconf-partial-lock-01

Hi Balazs,

I reviewed the -01 version of the = draft "Partial Lock RPC for NETCONF".
In general the draft looks good but = needs some improvements.

Please find below my comments:

Section 2.1., paragraph 2:

as David H. states please use = explicit wording from RFC 2119:
"MUST ensure" instead of = "ensures"

s/be//

Section 2.1., paragraph 3:

Would change for more clarity:
"The partial = lock operation starts = when the partial = lock is granted
and = lasts until either the corresponding <partial-unlock> operation
succeeds or = the NETCONF session = terminates."

Section = 2.2.:

Please use MUST = or SHOULD to indicate what needs to be supported
as a minimum = and what can be supported additionally.

Section 2.4.1., = paragraph 4:

I was wondering = whether we need more explanation of the atomic
operation. I = would suggest to extend the text with following for clarity =
even if it = looks redundant:

"I.e., the = server MUST ensure to unlock all already locked parts if one =
of the = requested parts cannot be locked."

Section 2.4.1., = paragraph 7, bullet 2:

The conclusion = of the discussion last December was that we don't
want to change = Netconf RFC chapter 7.5, which says:
"An = attempt to lock the configuration MUST fail if an existing session =
or other entity = holds a lock on any portion of the lock target."

The wording = "another management sesion" implies excluding the current = session.
Based on the = conclusion of our discussion, "overlapping partial locks by the =
same session = are not allowed", I would suggest to change 2nd bullet = to:

o  Any = part of the scope to be locked is already locked by any
   management = session/protocol, including the current session and
   = other NETCONF = sessions using the <partial-lock> or any = other
   non-NETCONF = management method.

Section 2.4.1., = paragraph 7, bullet 3:

IMO = "at least some basic access rights" is too vague. We = need to state
explicitely = which access rights are necessary.
I assume the = reason why a session uses partial-lock is to be able to write = in
an atomic way = (this is at least mentioned in Section 2.4.1., paragraph = 9). =
So, why is it = sufficient to have "read rights"? Was the intention here to = prevent
others from = writing?

Section 2.4.1., = paragraph 8:

I would like to = suggest to use more explicite wording.
I assume you = mean "sessions" if you say "users" and  = "different locking scopes"
if you say = "different parts".

My question is: = How is it possible that two sessions trying to lock "different =
parts" get = dead-locked? IMO the dead-lock happens only if session A and =
session B try = to lock the "same locking scope" and session A does not free =
the = partial-lock it executed and session B waits forever.

Based on the = rule defined in Section 2.4.1., paragraph 4 the partial-lock =
(of potentially = many lock areas) is handled in an atomic way. So i.e.:
Locking a set = of "locking scopes" is a good strategy if session A doesn't =
want to be = disturbed during it's work.
Locking a set = of "locking scopes" at once does not help against waiting =
of session B if = something is already locked by session A.

Section 2.4.1., = paragraph 9:

I would skip = "you get what you asked for".
"It is the = intention to keep partial-locking simple. Partial
lock = aims to lock a set of nodes for writing only."

I would like to ask = the same question as David H. What are the issues
that are = intentionally not addressed. But I see in your mail that you want =
to s/./:/ = ;-).

Section 2.4.1., = paragraph 9, bullet 2 and 3:

'Section 2.4.1., = paragraph 8', 'Section 2.4.1., paragraph 9, bullet 2' and
'Section = 2.4.1., 9th paragraph, bullet 3' have the same general statement =
in mind and = seem to be redundant. I would reduce some of the redundant =
text with a = clear statement:

"It is the = operator's responsibility to lock all parts of = the
datastore that = are crucial for a specific management = action."

Section 2.4.1., = paragraph 10:

It is = interesting for clarity if you add this or exchange it with parts of = the
current = text:

"Partial = and global lock follow the same rules as defined in = RFC4741."

Section 2.4.1., = paragraph 16 (beginning with "If any select expression =
returns = anything but …"):

I don't agree = with David H., if the select expression is erroneous the
<error-tag> = shall be 'invalid-value'.
Also here we = should use RFC 2119 wording: "SHALL"

I would change the = paragraph for more clarity:
"If the select expression is = erroneous and does not point to
a node set, = the <error-tag> SHALL be = 'invalid-value'.

Section = 3.:

IMO it is = important to extend this section. We should state what we mean =
with "some = access control mechanism" at least to some extend and = although
we have no = access control draft yet.

<***>
A general issue = I anticipate here is that we most likely cannot get the
"Partial = Lock" draft and also other drafts which depend on "NETCONF =
access control = mechanisms" through the IESG. I assume IESG will ask
for it as a = companion draft and we need to provide the AC mechanism
in parallel. We = should discuss this on the maillist and need also the advice =
of = Dan.
</***>

Section = 4.:

Since we had some = issues during the shepperding of the Notifications
draft I would like = to suggest to use the wording and template from the
Notifications = draft (other useful examples are available in RFC 4825).

Appendix = A:

I would divide it = in two sub-sections or appendices: Change log, Open = issues.

Appendix A - Open = Issues:

I think we = shouldn't introduce a special rule for locking non-existent nodes. =
IMO it is better = if the operator creates "empty nodes" if he wants to = reserve
an object or it's = name/key.

We should include = more detailed information in error results to help debug
lock conflicts but = how detailed should this information be. If you are in
favor please = provide a proposal and we can discuss and decide in the = WG.

IMO we should allow = users to lock parts of multiple datastores. This is in
support of the = "atomic lock operation" for a set of "locking = scopes" at once,
which is useful = and necessary even beyond the borders of a datastore and
even the current = (global) <lock> operation does not support this.

Appendix B, = C:

I understand you = would like to see YANG as the "normative DML" but we =
need to choose one = of the models in the appendices as the normative
reference of = today. As I understood Dan correctly, currently XSD can be =
used as a the = "normative reference".

Section = 9.:

Please add YANG = draft to the list of references.

Cheers,
Mehmet


------_=_NextPart_001_01C87DF9.8C698464-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From netconf-bounces@ietf.org Tue Mar 4 13:43:39 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD6828C650; Tue, 4 Mar 2008 13:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.829 X-Spam-Level: X-Spam-Status: No, score=0.829 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkitq7cOTFkT; Tue, 4 Mar 2008 13:43:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9476D28C673; Tue, 4 Mar 2008 13:43:36 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB14028C666 for ; Tue, 4 Mar 2008 13:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJp8kkJQhd0d for ; Tue, 4 Mar 2008 13:43:34 -0800 (PST) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 17E1D28C6A9 for ; Tue, 4 Mar 2008 13:42:52 -0800 (PST) Received: (qmail 84100 invoked from network); 4 Mar 2008 21:42:43 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Mar 2008 21:42:43 -0000 From: "Bert Wijnen - IETF" To: Date: Tue, 4 Mar 2008 22:42:48 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] testing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org See if this gets posted Bert Wijnen _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Mar 4 22:41:21 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22A93A6A52; Tue, 4 Mar 2008 22:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.754 X-Spam-Level: X-Spam-Status: No, score=0.754 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krP5BCynLR4t; Tue, 4 Mar 2008 22:41:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF9A3A6783; Tue, 4 Mar 2008 22:41:21 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5EA3A6818 for ; Tue, 4 Mar 2008 22:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9pPXLu63UrM for ; Tue, 4 Mar 2008 22:41:19 -0800 (PST) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 6723F3A6783 for ; Tue, 4 Mar 2008 22:41:19 -0800 (PST) Received: (qmail 35418 invoked from network); 5 Mar 2008 06:41:08 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 5 Mar 2008 06:41:08 -0000 From: "Bert Wijnen - IETF" To: Date: Wed, 5 Mar 2008 07:41:13 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] does this one get archived correctly (posted to netconf at ietf.org) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Just checking if archiving goes OK Bert Wijnen _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From owner-netconf@ops.ietf.org Tue Mar 4 23:00:12 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF5528C194 for ; Tue, 4 Mar 2008 23:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.874 X-Spam-Level: X-Spam-Status: No, score=0.874 tagged_above=-999 required=5 tests=[AWL=-1.289, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaB3AX1ekq46 for ; Tue, 4 Mar 2008 23:00:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9D873A6C8E for ; Tue, 4 Mar 2008 23:00:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWnJS-000MaJ-9H for netconf-data@psg.com; Wed, 05 Mar 2008 06:41:14 +0000 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWnJP-000MZj-Lr for netconf@ops.ietf.org; Wed, 05 Mar 2008 06:41:12 +0000 Received: (qmail 35420 invoked from network); 5 Mar 2008 06:41:08 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 5 Mar 2008 06:41:08 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Subject: does this one get archived correctly (posted to netconf at ops.ietf.org) Date: Wed, 5 Mar 2008 07:41:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk Just checking if archiving goes OK Bert Wijnen -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From netconf-bounces@ietf.org Wed Mar 5 01:57:03 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD3228C75E for ; Wed, 5 Mar 2008 01:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk9Wn8IOB6+j for ; Wed, 5 Mar 2008 01:57:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BAD428C795 for ; Wed, 5 Mar 2008 01:56:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Welcome to the "Netconf" mailing list From: netconf-request@ietf.org To: netconf-archive@lists.ietf.org X-No-Archive: yes Message-ID: Date: Wed, 05 Mar 2008 01:56:50 -0800 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi All, this is the announcement of the long awaited NETCONF maillist on "ietf.org". We moved all mail addresses to the new maillist so that you don't need to do anything. Currently the NETCONF maillist history is not available on ietf.org. This is going to be fixed soon. Have fun! Mehmet ______________________________________________________________________ Welcome to the Netconf@ietf.org mailing list! To post to this list, send your email to: netconf@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/netconf If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www.ietf.org/mailman/options/netconf/netconf-archive%40lists.ietf.org You can also make such adjustments via email by sending a message to: Netconf-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: WOXI7bMi Normally, Mailman will remind you of your ietf.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. From owner-netconf@ops.ietf.org Wed Mar 5 02:10:48 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CE528C6D4 for ; Wed, 5 Mar 2008 02:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=1.472, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAM84FiUsuwI for ; Wed, 5 Mar 2008 02:10:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFCFD3A69B1 for ; Wed, 5 Mar 2008 02:10:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWqRB-0002aK-6t for netconf-data@psg.com; Wed, 05 Mar 2008 10:01:25 +0000 Received: from [217.115.75.233] (helo=demumfd001.nsn-inter.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWqR7-0002Zk-Rz for netconf@ops.ietf.org; Wed, 05 Mar 2008 10:01:23 +0000 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m25A1HJl027575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2008 11:01:17 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m25A1Cm6006607; Wed, 5 Mar 2008 11:01:17 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Mar 2008 11:01:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: NETCONF maillist on 'ops.ietf.org' going down Date: Wed, 5 Mar 2008 11:01:13 +0100 Message-ID: In-Reply-To: <18376.33817.47526.548119@switch.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF maillist on 'ops.ietf.org' going down Thread-Index: Ach7IK2udxxotcyIQ22cHP9Yv9svzQDEN86w References: <18376.33817.47526.548119@switch.ch> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Simon Leinen" Cc: "ext Bert Wijnen - IETF" , X-OriginalArrivalTime: 05 Mar 2008 10:01:14.0592 (UTC) FILETIME=[D908A600:01C87EA7] Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Simon, the new NETCONF maillist has been created successfully=20 and started the operational mode. Could you please now close the old maillist? Now Bert and myself will take care of the new maillist. Thank you for your kind support and efforts in the last=20 years. Cheers,=20 Mehmet=20 =20 > -----Original Message----- > From: ext Simon Leinen [mailto:simon.leinen@switch.ch]=20 > Sent: Friday, February 29, 2008 11:16 PM > To: Ersue, Mehmet (NSN - DE/Muenich) > Cc: ext Bert Wijnen - IETF > Subject: Re: FW: Request to move the WG email list for=20 > netconf to ietf.org >=20 > "Ersue, Mehmet (NSN writes: > > Could you please send me the current list of mail adresses > > which are subscribed to the old maillist (@ops.ietf.org)? >=20 > Sure, here comes a fresh copy from psg.com:~majordom/lists/netconf! >=20 > Best regards, > --=20 > Simon. >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 5 13:02:01 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E3D3A6F45 for ; Wed, 5 Mar 2008 13:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaKtkyEnDYYU for ; Wed, 5 Mar 2008 13:02:00 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 093C23A6F2D for ; Wed, 5 Mar 2008 13:02:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JX0ZX-000Ge4-S5 for netconf-data@psg.com; Wed, 05 Mar 2008 20:50:43 +0000 Received: from [76.96.30.80] (helo=QMTA08.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWcJw-000Pfv-7z for netconf@ops.ietf.org; Tue, 04 Mar 2008 18:57:01 +0000 Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id x6D41Y0090mlR8UA804z00; Tue, 04 Mar 2008 18:56:27 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id x6wu1Y00B4HwxpC8X00000; Tue, 04 Mar 2008 18:56:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=Bq32yB4Oe1IkBOBH82sA:9 a=O55bfOYF7s8adg1fSkkA:7 a=IbXmLpljvPhBh-eeKCkmxC-vdqYA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Subject: revew of linowski requirements-00 Date: Tue, 4 Mar 2008 13:56:54 -0500 Message-ID: <010b01c87e29$8421ddb0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ach+KYNLbWKiGq4UT3KRtF8d9HN7Yg== Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, I have reviewed this document, and have some comments. My main impression is that this is not a list of requirements, but a wish list of nice to have features. We have already seen many of these items raised during the SMING WG, but many add complexity without providing significant benefit to over-the-wire management information sharing, especially to operators who are not data modeling theorists. A number of these requirements are suggested application-development solutions that might benefit manager application developers, but they can use object oriented languages such as C++ and Java with various application-support libraries, such as GUI libraries, and application-appropriate database designs to get what they need in the application. But that does not make them features that are REQUIRED for over-the-wire protocols to utilize to share data in an interoperable manner amongst multiple manager applications and managed entities. I used to work on an industry-leading NMS application, and we used C++, and object-oriented database modeling with support for inheritance, and SQL queries and fancy GUIs, and these were important to making the application user-friendly, but those features certainly do not belong in an on-the-wire protocol suite for gathering vendor-neutral standardized data from managed entities, especially when some of those entities might be tremendously resource constrained. Data modeling for programming applications and data modeling for standardized over-the-wire data gathering have distinctly different sets of requirements. -- Here are my detailed comments: section 3. "data model" definition requires some rewording to make it good English. 4.2.2. English and ASCII are required for purposes of IETF "interoperability" during standardization; English and ASCII have been established as the standards for sharing proposals within the IETF, to make those proposals reviewable by IETF members. It is generally not acceptable to propose IETF standards in other languages or language-specific characters (except when standardizing what character set a value might contain). It might be acceptable for proprietary data models, but not IETF standard data models. 4.2.2. There is a Note that expresses an opinion, but that opinion is not necessarily accepted as consensus. I'm not sure I agree it belongs here without at least mentioning the opposing view. 4.2.3. I would reword "All kinds of characters, including language specific characters must be supported." First, "all kinds" encompasses much more than we need to encompass. If the local Star Trek fan club develops a new, non-standard, version of Klingon, must that be supported? Second, there are some fields which make protocol sense to express in local languages, but there are other fields that probably should not be. That's why SNMP has DisplayStrings and SnmpAdminStrings - to limit the range of characters used in specific fields such as index clauses. Lexicographical ordering is already hard enough without having to deal with lexicographical ordering across different, possibly non-standard, languages. It is not good practice to require that an agent in a resource-constrained device must support a wide range of character sets unnecessarily. I don't feel that it is a requirement to be able to support data entry field captions within a data model; the approrpiate data enrty field captions will depende greatly on the application and the users of that application. I would not want to have to specify as part of a standard the appropriate data entry field captions for every known language for every object in the data model. 4.3.1 Why is it a requirement that the release identifier support the dot character? Is this presupposing a specific format that has not been agreed to? I don't understand the sentence "Typing versions to individual model elements in one release agnostic (compound-) model wouldn't be practical." It might be better to reword this. "as a release specific views" - plurality needs to be consistent. 4.3.2 I agree manager applications need to be able to handle different revisions of the same data model simultaneously to represent different managed implementations. I do not agree this is a requirement of the data model for use with an over-the-wire protocol; this is a local database requirement for the manager application. It is, however, important to be able to distinguish instances of MIB modules on a managed entity, as is provided by the community or context concepts of SNMP, since this is important for over-the-wire interoperability. It would be useful to be able to query a managed entity to determine which MIB revision (or compliance level) is supported. One issue with this requirement is that we are dealing with standards, and the definitions (semantics) for elements typically should not change across revisions, with few clearly defined exceptions to this rule such as those identified in SMIv2. If the semantics change, the element identifier should be changed as well. So I question whether a named item needs to be scoped by its revision; the name and semantics of a managed object should be consistent across revisions. 4.4 In my experience, operators usually do not think in object-oriented terms. Programmers often do. Defining models in object-oriented terms makes it harder-to-use for operators. Features like concrete and abstract classes and inheritance are focused on the wrong audience for network management. There are some serious issues with moving toward an object-oriented approach. Searching for matching data inside nested objects becomes harder, in much the same way that multiple nested levels of menus in a GUI can make it harder for a user to find the option they are looking for. Hierarchical structures of inheritance can make it more difficult to merge different data models, in much the same way that Borland's C++ libraries and Microsoft's C++ libraries were difficult to use together; they were built on different roots and compounded their differences by inheriting a whole philosphy of hierarchical design. As a standards organization based on running code, we need the ability to merge data models from different vendors. If we go too far toward hierarchical nesting of data models, we reduce the ability to merge them into a standard. [I skipped over much of this document for lack of time ...] While some of these requiremnets might be useful features in a general-purpose DML, this document seems focused on a different problem space than data modeling for use with the Netconf protocol, or any over-the-wire network management protocol. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 5 13:16:50 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B032928C593 for ; Wed, 5 Mar 2008 13:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWHACeUOjtTt for ; Wed, 5 Mar 2008 13:16:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E80928C318 for ; Wed, 5 Mar 2008 13:16:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JX0pY-000KhE-SK for netconf-data@psg.com; Wed, 05 Mar 2008 21:07:16 +0000 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JX0pS-000KfE-OU for netconf@ops.ietf.org; Wed, 05 Mar 2008 21:07:15 +0000 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id A150B1B80C9; Wed, 5 Mar 2008 22:07:08 +0100 (CET) Date: Wed, 05 Mar 2008 22:07:07 +0100 (CET) Message-Id: <20080305.220707.96178408.mbj@tail-f.com> To: mehmet.ersue@nsn.com Cc: netconf@ops.ietf.org, bertietf@bwijnen.net, dromasca@avaya.com Subject: Re: Agenda for NETCONF WG session at IETF #71 From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, "Ersue, Mehmet (NSN - DE/Muenich)" wrote: [...] > Please let us know before hand about your implementation. [...] > 1. NETCONF over TLS (20 minutes) > > draft-ietf-netconf-tls-01.txt Since I still don't think that what's missing from NETCONF is yet another optional transport, I have not implemented this... > 2. Fine-grained locking (20 minutes) > > draft-ietf-netconf-partial-lock-00.txt I have implemented this draft, and it is part of our released software. > 3. Netconf monitoring (20 minutes) > > draft-ietf-netconf-monitoring-00.txt I have a (vendor-specific) implementation of most parts of this draft. This model is fairly trivial to implement, and I will implement this as soon as the draft stabilizes a bit. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Mar 6 07:05:20 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBCB3A6C38 for ; Thu, 6 Mar 2008 07:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQJPtwnCcVDp for ; Thu, 6 Mar 2008 07:05:15 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94E163A694E for ; Thu, 6 Mar 2008 07:05:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXHSL-000JB3-Fz for netconf-data@psg.com; Thu, 06 Mar 2008 14:52:25 +0000 Received: from [192.100.122.233] (helo=mgw-mx06.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXHS6-000J94-KM for netconf@ops.ietf.org; Thu, 06 Mar 2008 14:52:15 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m26EpV7n029468; Thu, 6 Mar 2008 16:52:00 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 16:51:57 +0200 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 16:51:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: revew of linowski requirements-00 Date: Thu, 6 Mar 2008 16:51:46 +0200 Message-ID: <99AAA0EB3F96B04CAAA1935181CF6DE5058760AA@esebe104.NOE.Nokia.com> In-Reply-To: <010b01c87e29$8421ddb0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: revew of linowski requirements-00 Thread-Index: Ach+KYNLbWKiGq4UT3KRtF8d9HN7YgBXbScA References: <010b01c87e29$8421ddb0$0600a8c0@china.huawei.com> From: To: Cc: X-OriginalArrivalTime: 06 Mar 2008 14:51:56.0977 (UTC) FILETIME=[9FEB2210:01C87F99] X-Nokia-AV: Clean Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, >-----Original Message----- >From: owner-netconf@ops.ietf.org=20 >[mailto:owner-netconf@ops.ietf.org] On Behalf Of ext David Harrington >Sent: 04.03.2008 20:57 >To: netconf@ops.ietf.org >Subject: revew of linowski requirements-00 > >Hi, > >I have reviewed this document, and have some comments.=20 > >My main impression is that this is not a list of requirements,=20 >but a wish list of nice to have features. We have already seen=20 >many of these items raised during the SMING WG, but many add=20 >complexity without providing significant benefit to=20 >over-the-wire management information sharing, especially to=20 >operators who are not data modeling theorists.=20 You are obviously free to have different opinion about the requirements, but that doesn't make a set of requirements any less a set of requirements :-) The benefit of object to the operators comes from tools that are not based on hard-coded models, but can adjust themselves to various data models, whether standard or implementation specific models. > >A number of these requirements are suggested=20 >application-development solutions that might benefit manager=20 >application developers, but they can use object oriented=20 >languages such as C++ and Java with various=20 >application-support libraries, such as GUI libraries, and=20 >application-appropriate database designs to get what they need=20 >in the application. But that does not make them features that=20 >are REQUIRED for over-the-wire protocols to utilize to share=20 >data in an interoperable manner amongst multiple manager=20 >applications and managed entities.=20 With a huge amount of models, standard and implementation specific extensions, it requires an enormous effort to implement such mapping classes on top of the models, and the mapping between the models is error-prone. Also, this causes delays in taking the new models into use because of need to implement these mapping classes after model has been designed. > >I used to work on an industry-leading NMS application, and we used >C++, and object-oriented database modeling with support for >inheritance, and SQL queries and fancy GUIs, and these were=20 >important to making the application user-friendly, but those=20 >features certainly do not belong in an on-the-wire protocol=20 >suite for gathering vendor-neutral standardized data from=20 >managed entities, especially when some of those entities might=20 >be tremendously resource constrained. The model inheritance does not imply extra resource requirements for the agent implementation. If you have classes A and B inheriting common base class C, the configuration data on the wire would be exactly same as if A and B would be defined independent of each other but sharing the same attributes. The difference is that a client capable of operating on instances of C knows that it can do the same with instances of A and B. > >Data modeling for programming applications and data modeling=20 >for standardized over-the-wire data gathering have distinctly=20 >different sets of requirements. Partly different, but object oriented concepts are applicable to both, and help to cope with growing complexity of models. > >-- > >Here are my detailed comments: > >section 3.=20 >"data model" definition requires some rewording to make it=20 >good English. > >4.2.2.=20 >English and ASCII are required for purposes of IETF "interoperability" >during standardization; English and ASCII have been=20 >established as the standards for sharing proposals within the=20 >IETF, to make those proposals reviewable by IETF members. It=20 >is generally not acceptable to propose IETF standards in other=20 >languages or language-specific characters (except when=20 >standardizing what character set a value might contain). It=20 >might be acceptable for proprietary data models, but not IETF=20 >standard data models. Netconf DML should be usable for standard and proprietary data models. Configuration management interoperability should not be available only within the limited set of standardized configuration models. > >4.2.2.=20 >There is a Note that expresses an opinion, but that opinion is=20 >not necessarily accepted as consensus. I'm not sure I agree it=20 >belongs here without at least mentioning the opposing view. So do you share that opposing view? If yes, could you be more specific as to what is your view on the documentation of models? > >4.2.3.=20 >I would reword "All kinds of characters, including language=20 >specific characters must be supported."=20 > >First, "all kinds" encompasses much more than we need to=20 >encompass. If the local Star Trek fan club develops a new,=20 >non-standard, version of Klingon, must that be supported? Perhaps Unicode would be enough :-) > >Second, there are some fields which make protocol sense to=20 >express in local languages, but there are other fields that=20 >probably should not be. That's why SNMP has DisplayStrings and=20 >SnmpAdminStrings - to limit the range of characters used in=20 >specific fields such as index clauses. >Lexicographical ordering is already hard enough without having=20 >to deal with lexicographical ordering across different,=20 >possibly non-standard, languages. It is not good practice to=20 >require that an agent in a resource-constrained device must=20 >support a wide range of character sets unnecessarily.=20 This is not required. In any case, IETF models obviously would only have English presentations, and it is up to the agent implementation whether it supports proprietary models (which might use other languages). > >I don't feel that it is a requirement to be able to support=20 >data entry field captions within a data model; the approrpiate=20 >data enrty field captions will depende greatly on the=20 >application and the users of that application. I would not=20 >want to have to specify as part of a standard the appropriate=20 >data entry field captions for every known language for every=20 >object in the data model.=20 The requirement here is that it is possible to give the presentation name to model elements, not that every model element would need to have a separate presentation name. Further on, this would not require you to provide name in every language. > >4.3.1 >Why is it a requirement that the release identifier support=20 >the dot character? Is this presupposing a specific format that=20 >has not been agreed to? No, this proposes a set of characters that at least should be supported for release identifier. Version numbers typically use dots, so I think dot is quite justified. But the DML could support some other characters as well. > >I don't understand the sentence "Typing versions to individual=20 >model elements in one release agnostic (compound-) model=20 >wouldn't be practical." It might be better to reword this. > >"as a release specific views" - plurality needs to be consistent. > >4.3.2 >I agree manager applications need to be able to handle=20 >different revisions of the same data model simultaneously to=20 >represent different managed implementations. I do not agree=20 >this is a requirement of the data model for use with an=20 >over-the-wire protocol; this is a local database requirement=20 >for the manager application. You could have several pluggable units within a network element, each having its own release. They do not necessarily share their data models. And those pluggable units can have their own pluggable sub-units. > >It is, however, important to be able to distinguish instances=20 >of MIB modules on a managed entity, as is provided by the=20 >community or context concepts of SNMP, since this is important=20 >for over-the-wire interoperability. It would be useful to be=20 >able to query a managed entity to determine which MIB revision=20 >(or compliance level) is supported. Just because multiple units within the agent have different releases of same model, there should be no need for a separate Netconf request. They should all be part of the complete model of the agent. > >One issue with this requirement is that we are dealing with=20 >standards, and the definitions (semantics) for elements=20 >typically should not change across revisions, with few clearly=20 >defined exceptions to this rule such as those identified in=20 >SMIv2. If the semantics change, the element identifier should=20 >be changed as well. So I question whether a named item needs=20 >to be scoped by its revision; the name and semantics of a=20 >managed object should be consistent across revisions. This might be the case with IETF models, but the DML should be usable for all models for Netconf, not just IETF standard models. > >4.4 >In my experience, operators usually do not think in=20 >object-oriented terms. Programmers often do. Defining models=20 >in object-oriented terms makes it harder-to-use for operators.=20 >Features like concrete and abstract classes and inheritance=20 >are focused on the wrong audience for network management. > >There are some serious issues with moving toward an=20 >object-oriented approach.=20 > >Searching for matching data inside nested objects becomes=20 >harder, in much the same way that multiple nested levels of=20 >menus in a GUI can make it harder for a user to find the=20 >option they are looking for.=20 This is not required by object oriented approach. If you don't prefer to use in your client GUI object oriented approach, you can treat classes as simple structures, expanding all inherited attributes and relationships from the base classes to the derived class. This wouldn't affect the configuration data on the wire. > >Hierarchical structures of inheritance can make it more=20 >difficult to merge different data models, in much the same way=20 >that Borland's C++ libraries and Microsoft's C++ libraries=20 >were difficult to use together; they were built on different=20 >roots and compounded their differences by inheriting a whole=20 >philosphy of hierarchical design. As a standards organization=20 >based on running code, we need the ability to merge data=20 >models from different vendors. If we go too far toward=20 >hierarchical nesting of data models, we reduce the ability to=20 >merge them into a standard. > In merging you probably wouldn't directly inherit from these vendor models (any more than you would directly import from vendor specific SNMP MIBs). And if you just reuse attributes from different vendor models via copying, the object-oriented approach does not prevent you from doing so. Regards, Mikko -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From netconf-bounces@ietf.org Thu Mar 6 12:04:30 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB8F28C9F6; Thu, 6 Mar 2008 12:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.574 X-Spam-Level: X-Spam-Status: No, score=-100.574 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CukcF7I8Rc5r; Thu, 6 Mar 2008 12:04:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017093A6F4C; Thu, 6 Mar 2008 12:03:20 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4FD3A6F45 for ; Thu, 6 Mar 2008 12:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov5Ui0GTdkmu for ; Thu, 6 Mar 2008 12:03:17 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0A01A28C996 for ; Thu, 6 Mar 2008 12:02:28 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m26K29Gb015553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 21:02:09 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m26K27HQ032059; Thu, 6 Mar 2008 21:02:07 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 21:02:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 21:02:05 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach57gEuw6AQNNRaSNi7tZf5zkwv0AF1ngAA References: From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 06 Mar 2008 20:02:07.0171 (UTC) FILETIME=[F4756130:01C87FC4] Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0532797428==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0532797428== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87FC4.F3D98ADC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87FC4.F3D98ADC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I uploaded the agenda and WG status slides: https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf =20 Presenters, please send me your slides prior to the=20 meeting. Thank you. =20 BTW: We still need minute takers ;-) =20 CU in Philly. Cheers, Mehmet =20 ________________________________ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, February 28, 2008 10:41 AM To: netconf@ops.ietf.org Cc: ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) Subject: Agenda for NETCONF WG session at IETF #71 =09 =09 Dear NETCONF WG,=20 below is an update for the agenda of the NETCONF WG session=20 at the IETF #71.=20 Our main focus in the session will be on open issue discussion.=20 Please let us know before hand about your implementation.=20 Please let us also know whether you have a concrete topic for=20 the open mic session.=20 We still need volunteers as scribe and minute taker. As you=20 know the session will not start before we have them ;-).=20 Bert & Mehmet=20 _____________________________________________=20 NETCONF WG=20 IETF 71, Philadelphia, PA, USA=20 MONDAY, March 10, 2008 1740-1950=20 Scribes (needs to be organized before the session),=20 Agenda bashing (2 minutes)=20 Use of mailing lists,=20 WG status review (10 minutes)=20 Current charter items:=20 1. NETCONF over TLS (20 minutes)=20 draft-ietf-netconf-tls-01.txt=20 2. Fine-grained locking (20 minutes)=20 draft-ietf-netconf-partial-lock-00.txt=20 3. Netconf monitoring (20 minutes)=20 draft-ietf-netconf-monitoring-00.txt=20 Discussion on ongoing implementations (10 minutes)=20 Who is implementing what?=20 Should we plan an interop-event for testing of=20 RFC 4141-4144 to get them to DS?=20 AOB=20 Open mike=20 One hot topic is e.g. the NETCONF-related requirements on DML.=20 Any other hot topics to discuss?=20 Note (this is not part of the agenda):=20 We are not going to discuss solutions in open mic slot.=20 This is just because we have some time and want to give=20 you the opportunity to sort out the NETCONF-related=20 requirements as a preparation for the Canmod BoF.=20 ------_=_NextPart_001_01C87FC4.F3D98ADC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for NETCONF WG session at IETF #71
Hi All,
 
I uploaded the agenda and WG status=20 slides:
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Presenters, please send me your = slides prior to=20 the
meeting. Thank you.
 
BTW: We still need minute takers=20 ;-)
 
CU in Philly.

Cheers,
Mehmet

 

From: owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN=20 - DE/Muenich)
Sent: Thursday, February 28, 2008 10:41=20 AM
To: netconf@ops.ietf.org
Cc: ext Bert Wijnen - = IETF;=20 ext Romascanu, Dan (Dan)
Subject: Agenda for NETCONF WG = session at=20 IETF #71


Dear NETCONF = WG,

below is an update = for the agenda=20 of the NETCONF WG session
at the IETF #71.

Our main focus in the = session will=20 be on open issue discussion.
Please let us know before hand about your=20 implementation.
Please let us also know whether you have a concrete topic for =
the = open mic=20 session.

We still need = volunteers as scribe=20 and minute taker. As you
know the session will not start before we have them ;-).=20

Bert & = Mehmet=20

_____________________________________________ =

NETCONF = WG
IETF 71, Philadelphia, PA, = USA=20

MONDAY, March 10, = 2008=20 1740-1950

  Scribes (needs = to be=20 organized before the session),
  Agenda bashing (2 = minutes)

  Use of mailing = lists,
  WG=20 status review (10 minutes)

  Current = charter=20 items:

    1. = NETCONF over=20 TLS (20 minutes)

      =20 draft-ietf-netconf-tls-01.txt

    2. = Fine-grained=20 locking (20 minutes)

      =20 draft-ietf-netconf-partial-lock-00.txt

    3. = Netconf=20 monitoring (20 minutes)

      =20 draft-ietf-netconf-monitoring-00.txt

  Discussion on = ongoing=20 implementations (10 minutes)

      Who=20 is implementing what?
      Should we plan an = interop-event for=20 testing of
      RFC 4141-4144 to get them to = DS?=20

  = AOB

  Open mike =

      One=20 hot topic is e.g. the NETCONF-related requirements on DML.=20
      Any other hot topics to = discuss?=20

Note (this is not = part of the=20 agenda):
We are not=20 going to discuss solutions in open mic slot.
This is just because we have = some time and=20 want to give
you the=20 opportunity to sort out the NETCONF-related
requirements as a preparation = for the Canmod=20 BoF. =


------_=_NextPart_001_01C87FC4.F3D98ADC-- --===============0532797428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0532797428==-- From netconf-bounces@ietf.org Thu Mar 6 12:04:30 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB8F28C9F6; Thu, 6 Mar 2008 12:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.574 X-Spam-Level: X-Spam-Status: No, score=-100.574 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CukcF7I8Rc5r; Thu, 6 Mar 2008 12:04:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017093A6F4C; Thu, 6 Mar 2008 12:03:20 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4FD3A6F45 for ; Thu, 6 Mar 2008 12:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov5Ui0GTdkmu for ; Thu, 6 Mar 2008 12:03:17 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0A01A28C996 for ; Thu, 6 Mar 2008 12:02:28 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m26K29Gb015553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 21:02:09 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m26K27HQ032059; Thu, 6 Mar 2008 21:02:07 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 21:02:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 21:02:05 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach57gEuw6AQNNRaSNi7tZf5zkwv0AF1ngAA References: From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 06 Mar 2008 20:02:07.0171 (UTC) FILETIME=[F4756130:01C87FC4] Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0532797428==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0532797428== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87FC4.F3D98ADC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87FC4.F3D98ADC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I uploaded the agenda and WG status slides: https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf =20 Presenters, please send me your slides prior to the=20 meeting. Thank you. =20 BTW: We still need minute takers ;-) =20 CU in Philly. Cheers, Mehmet =20 ________________________________ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, February 28, 2008 10:41 AM To: netconf@ops.ietf.org Cc: ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) Subject: Agenda for NETCONF WG session at IETF #71 =09 =09 Dear NETCONF WG,=20 below is an update for the agenda of the NETCONF WG session=20 at the IETF #71.=20 Our main focus in the session will be on open issue discussion.=20 Please let us know before hand about your implementation.=20 Please let us also know whether you have a concrete topic for=20 the open mic session.=20 We still need volunteers as scribe and minute taker. As you=20 know the session will not start before we have them ;-).=20 Bert & Mehmet=20 _____________________________________________=20 NETCONF WG=20 IETF 71, Philadelphia, PA, USA=20 MONDAY, March 10, 2008 1740-1950=20 Scribes (needs to be organized before the session),=20 Agenda bashing (2 minutes)=20 Use of mailing lists,=20 WG status review (10 minutes)=20 Current charter items:=20 1. NETCONF over TLS (20 minutes)=20 draft-ietf-netconf-tls-01.txt=20 2. Fine-grained locking (20 minutes)=20 draft-ietf-netconf-partial-lock-00.txt=20 3. Netconf monitoring (20 minutes)=20 draft-ietf-netconf-monitoring-00.txt=20 Discussion on ongoing implementations (10 minutes)=20 Who is implementing what?=20 Should we plan an interop-event for testing of=20 RFC 4141-4144 to get them to DS?=20 AOB=20 Open mike=20 One hot topic is e.g. the NETCONF-related requirements on DML.=20 Any other hot topics to discuss?=20 Note (this is not part of the agenda):=20 We are not going to discuss solutions in open mic slot.=20 This is just because we have some time and want to give=20 you the opportunity to sort out the NETCONF-related=20 requirements as a preparation for the Canmod BoF.=20 ------_=_NextPart_001_01C87FC4.F3D98ADC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for NETCONF WG session at IETF #71
Hi All,
 
I uploaded the agenda and WG status=20 slides:
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Presenters, please send me your = slides prior to=20 the
meeting. Thank you.
 
BTW: We still need minute takers=20 ;-)
 
CU in Philly.

Cheers,
Mehmet

 

From: owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN=20 - DE/Muenich)
Sent: Thursday, February 28, 2008 10:41=20 AM
To: netconf@ops.ietf.org
Cc: ext Bert Wijnen - = IETF;=20 ext Romascanu, Dan (Dan)
Subject: Agenda for NETCONF WG = session at=20 IETF #71


Dear NETCONF = WG,

below is an update = for the agenda=20 of the NETCONF WG session
at the IETF #71.

Our main focus in the = session will=20 be on open issue discussion.
Please let us know before hand about your=20 implementation.
Please let us also know whether you have a concrete topic for =
the = open mic=20 session.

We still need = volunteers as scribe=20 and minute taker. As you
know the session will not start before we have them ;-).=20

Bert & = Mehmet=20

_____________________________________________ =

NETCONF = WG
IETF 71, Philadelphia, PA, = USA=20

MONDAY, March 10, = 2008=20 1740-1950

  Scribes (needs = to be=20 organized before the session),
  Agenda bashing (2 = minutes)

  Use of mailing = lists,
  WG=20 status review (10 minutes)

  Current = charter=20 items:

    1. = NETCONF over=20 TLS (20 minutes)

      =20 draft-ietf-netconf-tls-01.txt

    2. = Fine-grained=20 locking (20 minutes)

      =20 draft-ietf-netconf-partial-lock-00.txt

    3. = Netconf=20 monitoring (20 minutes)

      =20 draft-ietf-netconf-monitoring-00.txt

  Discussion on = ongoing=20 implementations (10 minutes)

      Who=20 is implementing what?
      Should we plan an = interop-event for=20 testing of
      RFC 4141-4144 to get them to = DS?=20

  = AOB

  Open mike =

      One=20 hot topic is e.g. the NETCONF-related requirements on DML.=20
      Any other hot topics to = discuss?=20

Note (this is not = part of the=20 agenda):
We are not=20 going to discuss solutions in open mic slot.
This is just because we have = some time and=20 want to give
you the=20 opportunity to sort out the NETCONF-related
requirements as a preparation = for the Canmod=20 BoF. =


------_=_NextPart_001_01C87FC4.F3D98ADC-- --===============0532797428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0532797428==-- From netconf-bounces@ietf.org Thu Mar 6 13:11:54 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D3428C9AE; Thu, 6 Mar 2008 13:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.141 X-Spam-Level: X-Spam-Status: No, score=-100.141 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLJG0ZvNs4bW; Thu, 6 Mar 2008 13:11:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E2328C916; Thu, 6 Mar 2008 13:11:53 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F4F28C916 for ; Thu, 6 Mar 2008 13:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FohJwY8fgtd for ; Thu, 6 Mar 2008 13:11:51 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 0D47A28C2F4 for ; Thu, 6 Mar 2008 13:11:50 -0800 (PST) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id xqqM1Y0021HpZEsA70FB00; Thu, 06 Mar 2008 21:10:55 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id xxBW1Y0064HwxpC8a00000; Thu, 06 Mar 2008 21:11:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=ogM6KDja5iMA:10 a=48vgC7mUAAAA:8 a=SDXTC6qgPyLuP9V4mA8A:9 a=xZMGjjpuyZK9IbF-dpkA:7 a=kkuNI1Uk3uhoZ60CODuQqL5X-9oA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=Br_DGpVPXg2tlyj5RjUA:9 a=u10JQIQCKYPgZiQytA8A:7 a=ZplagqwzkgeMDvET7j83TD29zigA:4 a=AfD3MYMu9mQA:10 From: "David B Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: Date: Thu, 6 Mar 2008 16:11:29 -0500 Message-ID: <004001c87fce$a6a682e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Ach57gEuw6AQNNRaSNi7tZf5zkwv0AF1ngAAAAJ9bwA= Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092228700==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0092228700== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C87FA4.BDD07AE0" This is a multi-part message in MIME format. ------=_NextPart_000_0041_01C87FA4.BDD07AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, You use abbreviations in the agenda without spelling them out anywhere. What is AOB? I figuredFrom netconf-bounces@ietf.org Thu Mar 6 13:11:54 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D3428C9AE; Thu, 6 Mar 2008 13:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.141 X-Spam-Level: X-Spam-Status: No, score=-100.141 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLJG0ZvNs4bW; Thu, 6 Mar 2008 13:11:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E2328C916; Thu, 6 Mar 2008 13:11:53 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F4F28C916 for ; Thu, 6 Mar 2008 13:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FohJwY8fgtd for ; Thu, 6 Mar 2008 13:11:51 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 0D47A28C2F4 for ; Thu, 6 Mar 2008 13:11:50 -0800 (PST) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id xqqM1Y0021HpZEsA70FB00; Thu, 06 Mar 2008 21:10:55 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id xxBW1Y0064HwxpC8a00000; Thu, 06 Mar 2008 21:11:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=ogM6KDja5iMA:10 a=48vgC7mUAAAA:8 a=SDXTC6qgPyLuP9V4mA8A:9 a=xZMGjjpuyZK9IbF-dpkA:7 a=kkuNI1Uk3uhoZ60CODuQqL5X-9oA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=Br_DGpVPXg2tlyj5RjUA:9 a=u10JQIQCKYPgZiQytA8A:7 a=ZplagqwzkgeMDvET7j83TD29zigA:4 a=AfD3MYMu9mQA:10 From: "David B Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: Date: Thu, 6 Mar 2008 16:11:29 -0500 Message-ID: <004001c87fce$a6a682e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Ach57gEuw6AQNNRaSNi7tZf5zkwv0AF1ngAAAAJ9bwA= Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092228700==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0092228700== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C87FA4.BDD07AE0" This is a multi-part message in MIME format. ------=_NextPart_000_0041_01C87FA4.BDD07AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, You use abbreviations in the agenda without spelling them out anywhere. What is AOB? I figured it out, but AC isn't spelled out anywhere. dbh _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 06, 2008 3:02 PM To: netconf@ietf.org Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 Hi All, I uploaded the agenda and WG status slides: https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf Presenters, please send me your slides prior to the meeting. Thank you. BTW: We still need minute takers ;-) CU in Philly. Cheers, Mehmet _____ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, February 28, 2008 10:41 AM To: netconf@ops.ietf.org Cc: ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) Subject: Agenda for NETCONF WG session at IETF #71 Dear NETCONF WG, below is an update for the agenda of the NETCONF WG session at the IETF #71. Our main focus in the session will be on open issue discussion. Please let us know before hand about your implementation. Please let us also know whether you have a concrete topic for the open mic session. We still need volunteers as scribe and minute taker. As you know the session will not start before we have them ;-). Bert & Mehmet _____________________________________________ NETCONF WG IETF 71, Philadelphia, PA, USA MONDAY, March 10, 2008 1740-1950 Scribes (needs to be organized before the session), Agenda bashing (2 minutes) Use of mailing lists, WG status review (10 minutes) Current charter items: 1. NETCONF over TLS (20 minutes) draft-ietf-netconf-tls-01.txt 2. Fine-grained locking (20 minutes) draft-ietf-netconf-partial-lock-00.txt 3. Netconf monitoring (20 minutes) draft-ietf-netconf-monitoring-00.txt Discussion on ongoing implementations (10 minutes) Who is implementing what? Should we plan an interop-event for testing of RFC 4141-4144 to get them to DS? AOB Open mike One hot topic is e.g. the NETCONF-related requirements on DML. Any other hot topics to discuss? Note (this is not part of the agenda): We are not going to discuss solutions in open mic slot. This is just because we have some time and want to give you the opportunity to sort out the NETCONF-related requirements as a preparation for the Canmod BoF. ------=_NextPart_000_0041_01C87FA4.BDD07AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for NETCONF WG session at IETF #71
Hi,
 
You use abbreviations in the agenda without = spelling them=20 out anywhere.
What is AOB?
I figured it out, but AC isn't spelled out=20 anywhere.
 
dbh

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Thursday, March 06, 2008 3:02 = PM
To:=20 netconf@ietf.org
Subject: Re: [Netconf] Agenda for NETCONF = WG=20 session at IETF #71

Hi All,
 
I uploaded the agenda and WG status=20 slides:
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Presenters, please send me your = slides prior=20 to the
meeting. Thank=20 you.
 
BTW: We still need minute takers=20 ;-)
 
CU in Philly.

Cheers,
Mehmet

 

From: owner-netconf@ops.ietf.org = [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, = Mehmet=20 (NSN - DE/Muenich)
Sent: Thursday, February 28, 2008 10:41 = AM
To: netconf@ops.ietf.org
Cc: ext Bert Wijnen = - IETF;=20 ext Romascanu, Dan (Dan)
Subject: Agenda for NETCONF WG = session at=20 IETF #71


Dear NETCONF = WG,=20

below is an update = for the agenda=20 of the NETCONF WG session
at the IETF #71.

Our main focus in = the session=20 will be on open issue discussion.
Please let us know before hand about your=20 implementation.
Please let us also know whether you have a concrete topic = for=20
the = open mic=20 session.

We still need = volunteers as=20 scribe and minute taker. As you
know the session will not start before we = have them ;-).=20

Bert & = Mehmet=20

_____________________________________________ =

NETCONF = WG=20
IETF 71, = Philadelphia, PA,=20 USA

MONDAY, March 10, = 2008=20 1740-1950

  Scribes = (needs to be=20 organized before the session),
  Agenda bashing (2 = minutes)

  Use of = mailing=20 lists,
  WG=20 status review (10 minutes)

  Current = charter=20 items:

    = 1. NETCONF=20 over TLS (20 minutes)

      =20 draft-ietf-netconf-tls-01.txt

    = 2.=20 Fine-grained locking (20 minutes)

      =20 draft-ietf-netconf-partial-lock-00.txt

    = 3. Netconf=20 monitoring (20 minutes)

      =20 draft-ietf-netconf-monitoring-00.txt

  Discussion = on ongoing=20 implementations (10 minutes)

     =20 Who is implementing what?
      Should we plan an = interop-event for=20 testing of
      RFC 4141-4144 to get them to = DS?=20

  = AOB

  Open mike=20

     =20 One hot topic is e.g. the NETCONF-related requirements on DML.=20
      Any other hot topics to = discuss?=20

Note (this is not = part of the=20 agenda):
We are=20 not going to discuss solutions in open mic slot. =
This is just because we have = some time and=20 want to give
you=20 the opportunity to sort out the NETCONF-related =
requirements as a = preparation for the=20 Canmod BoF.=20


------=_NextPart_000_0041_01C87FA4.BDD07AE0-- --===============0092228700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0092228700==-- it out, but AC isn't spelled out anywhere. dbh _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 06, 2008 3:02 PM To: netconf@ietf.org Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 Hi All, I uploaded the agenda and WG status slides: https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf Presenters, please send me your slides prior to the meeting. Thank you. BTW: We still need minute takers ;-) CU in Philly. Cheers, Mehmet _____ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, February 28, 2008 10:41 AM To: netconf@ops.ietf.org Cc: ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) Subject: Agenda for NETCONF WG session at IETF #71 Dear NETCONF WG, below is an update for the agenda of the NETCONF WG session at the IETF #71. Our main focus in the session will be on open issue discussion. Please let us know before hand about your implementation. Please let us also know whether you have a concrete topic for the open mic session. We still need volunteers as scribe and minute taker. As you know the session will not start before we have them ;-). Bert & Mehmet _____________________________________________ NETCONF WG IETF 71, Philadelphia, PA, USA MONDAY, March 10, 2008 1740-1950 Scribes (needs to be organized before the session), Agenda bashing (2 minutes) Use of mailing lists, WG status review (10 minutes) Current charter items: 1. NETCONF over TLS (20 minutes) draft-ietf-netconf-tls-01.txt 2. Fine-grained locking (20 minutes) draft-ietf-netconf-partial-lock-00.txt 3. Netconf monitoring (20 minutes) draft-ietf-netconf-monitoring-00.txt Discussion on ongoing implementations (10 minutes) Who is implementing what? Should we plan an interop-event for testing of RFC 4141-4144 to get them to DS? AOB Open mike One hot topic is e.g. the NETCONF-related requirements on DML. Any other hot topics to discuss? Note (this is not part of the agenda): We are not going to discuss solutions in open mic slot. This is just because we have some time and want to give you the opportunity to sort out the NETCONF-related requirements as a preparation for the Canmod BoF. ------=_NextPart_000_0041_01C87FA4.BDD07AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for NETCONF WG session at IETF #71
Hi,
 
You use abbreviations in the agenda without = spelling them=20 out anywhere.
What is AOB?
I figured it out, but AC isn't spelled out=20 anywhere.
 
dbh

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Thursday, March 06, 2008 3:02 = PM
To:=20 netconf@ietf.org
Subject: Re: [Netconf] Agenda for NETCONF = WG=20 session at IETF #71

Hi All,
 
I uploaded the agenda and WG status=20 slides:
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Presenters, please send me your = slides prior=20 to the
meeting. Thank=20 you.
 
BTW: We still need minute takers=20 ;-)
 
CU in Philly.

Cheers,
Mehmet

 

From: owner-netconf@ops.ietf.org = [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, = Mehmet=20 (NSN - DE/Muenich)
Sent: Thursday, February 28, 2008 10:41 = AM
To: netconf@ops.ietf.org
Cc: ext Bert Wijnen = - IETF;=20 ext Romascanu, Dan (Dan)
Subject: Agenda for NETCONF WG = session at=20 IETF #71


Dear NETCONF = WG,=20

below is an update = for the agenda=20 of the NETCONF WG session
at the IETF #71.

Our main focus in = the session=20 will be on open issue discussion.
Please let us know before hand about your=20 implementation.
Please let us also know whether you have a concrete topic = for=20
the = open mic=20 session.

We still need = volunteers as=20 scribe and minute taker. As you
know the session will not start before we = have them ;-).=20

Bert & = Mehmet=20

_____________________________________________ =

NETCONF = WG=20
IETF 71, = Philadelphia, PA,=20 USA

MONDAY, March 10, = 2008=20 1740-1950

  Scribes = (needs to be=20 organized before the session),
  Agenda bashing (2 = minutes)

  Use of = mailing=20 lists,
  WG=20 status review (10 minutes)

  Current = charter=20 items:

    = 1. NETCONF=20 over TLS (20 minutes)

      =20 draft-ietf-netconf-tls-01.txt

    = 2.=20 Fine-grained locking (20 minutes)

      =20 draft-ietf-netconf-partial-lock-00.txt

    = 3. Netconf=20 monitoring (20 minutes)

      =20 draft-ietf-netconf-monitoring-00.txt

  Discussion = on ongoing=20 implementations (10 minutes)

     =20 Who is implementing what?
      Should we plan an = interop-event for=20 testing of
      RFC 4141-4144 to get them to = DS?=20

  = AOB

  Open mike=20

     =20 One hot topic is e.g. the NETCONF-related requirements on DML.=20
      Any other hot topics to = discuss?=20

Note (this is not = part of the=20 agenda):
We are=20 not going to discuss solutions in open mic slot. =
This is just because we have = some time and=20 want to give
you=20 the opportunity to sort out the NETCONF-related =
requirements as a = preparation for the=20 Canmod BoF.=20


------=_NextPart_000_0041_01C87FA4.BDD07AE0-- --===============0092228700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0092228700==-- From netconf-bounces@ietf.org Thu Mar 6 13:47:55 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772033A6E13; Thu, 6 Mar 2008 13:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.511 X-Spam-Level: X-Spam-Status: No, score=-100.511 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve8FS-t-+p3R; Thu, 6 Mar 2008 13:47:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C5E3A6A92; Thu, 6 Mar 2008 13:47:54 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D1C28C260 for ; Thu, 6 Mar 2008 13:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nKhNkGd0pJi for ; Thu, 6 Mar 2008 13:47:47 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 98AEA3A6E00 for ; Thu, 6 Mar 2008 13:47:46 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m26LlToi006559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 22:47:29 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m26LlR3i003130; Thu, 6 Mar 2008 22:47:29 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 22:47:26 +0100 MIME-Version: 1.0 Date: Thu, 6 Mar 2008 22:47:24 +0100 Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <004001c87fce$a6a682e0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach57gEuw6AQNNRaSNi7tZf5zkwv0AF1ngAAAAJ9bwAAAT+QUA== References: <004001c87fce$a6a682e0$0600a8c0@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext David B Harrington" , X-OriginalArrivalTime: 06 Mar 2008 21:47:26.0968 (UTC) FILETIME=[AB59DF80:01C87FD3] Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1736431440==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1736431440== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87FD3.B30BBFE4" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C87FD3.B30BBFE4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry about that, AC is meant to be "Access Control". =20 Cheers, Mehmet =20 ________________________________ From: ext David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Thursday, March 06, 2008 10:11 PM To: Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] Agenda for NETCONF WG session at IETF #71 =09 =09 Hi, =20 You use abbreviations in the agenda without spelling them out anywhere. What is AOB? I figured it out, but AC isn't spelled out anywhere. =20 dbh ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 06, 2008 3:02 PM To: netconf@ietf.org Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 =09 =09 Hi All, =20 I uploaded the agenda and WG status slides: =09 https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf =20 Presenters, please send me your slides prior to the=20 meeting. Thank you. =20 BTW: We still need minute takers ;-) =20 CU in Philly. Cheers, Mehmet =09 =20 ________________________________ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, February 28, 2008 10:41 AM To: netconf@ops.ietf.org Cc: ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) Subject: Agenda for NETCONF WG session at IETF #71 =09 =09 Dear NETCONF WG,=20 below is an update for the agenda of the NETCONF WG session=20 at the IETF #71.=20 Our main focus in the session will be on open issue discussion.=20 Please let us know before hand about your implementation.=20 Please let us also know whether you have a concrete topic for=20 the open mic session.=20 We still need volunteers as scribe and minute taker. As you=20 know the session will not start before we have them ;-).=20 Bert & Mehmet=20 _____________________________________________=20 NETCONF WG=20 IETF 71, Philadelphia, PA, USA=20 MONDAY, March 10, 2008 1740-1950=20 Scribes (needs to be organized before the session),=20 Agenda bashing (2 minutes)=20 Use of mailing lists,=20 WG status review (10 minutes)=20 Current charter items:=20 1. NETCONF over TLS (20 minutes)=20 draft-ietf-netconf-tls-01.txt=20 2. Fine-grained locking (20 minutes)=20 draft-ietf-netconf-partial-lock-00.txt=20 3. Netconf monitoring (20 minutes)=20 draft-ietf-netconf-monitoring-00.txt=20 Discussion on ongoing implementations (10 minutes)=20 Who is implementing what?=20 Should we plan an interop-event for testing of=20 RFC 4141-4144 to get them to DS?=20 AOB=20 Open mike=20 One hot topic is e.g. the NETCONF-related requirements on DML.=20 Any other hot topics to discuss?=20 Note (this is not part of the agenda):=20 We are not going to discuss solutions in open mic slot.=20 This is just because we have some time and want to give=20 you the opportunity to sort out the NETCONF-related=20 requirements as a preparation for the Canmod BoF.=20 ------_=_NextPart_001_01C87FD3.B30BBFE4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for NETCONF WG session at IETF #71
Sorry about that, AC is meant to be "Access=20 Control".
 
Cheers,
Mehmet
 

From: ext David B Harrington=20 [mailto:dbharrington@comcast.net]
Sent: Thursday, March 06, = 2008=20 10:11 PM
To: Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Subject: RE: [Netconf] Agenda for NETCONF = WG=20 session at IETF #71

Hi,
 
You use abbreviations in the agenda without = spelling them=20 out anywhere.
What is AOB?
I figured it out, but AC isn't spelled out=20 anywhere.
 
dbh

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Thursday, March 06, 2008 3:02 = PM
To:=20 netconf@ietf.org
Subject: Re: [Netconf] Agenda for NETCONF = WG=20 session at IETF #71

Hi All,
 
I uploaded the agenda and WG status=20 slides:
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Presenters, please send me your = slides=20 prior to the
meeting. Thank=20 you.
 
BTW: We still need minute takers=20 ;-)
 
CU in Philly.

Cheers,
Mehmet

 

From: = owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, = Mehmet=20 (NSN - DE/Muenich)
Sent: Thursday, February 28, 2008 = 10:41=20 AM
To: netconf@ops.ietf.org
Cc: ext Bert = Wijnen -=20 IETF; ext Romascanu, Dan (Dan)
Subject: Agenda for = NETCONF WG=20 session at IETF #71


Dear NETCONF = WG,=20

below is an = update for the=20 agenda of the NETCONF WG session
at the IETF #71.

Our main focus in = the session=20 will be on open issue discussion.
Please let us know before hand about your=20 implementation.
Please let us also know whether you have a concrete topic = for=20
the open mic=20 session.

We still need = volunteers as=20 scribe and minute taker. As you
know the session will not start before we = have them=20 ;-).

Bert & = Mehmet=20

_____________________________________________ =

NETCONF = WG=20
IETF 71, = Philadelphia, PA,=20 USA

MONDAY, March 10, = 2008=20 1740-1950

  Scribes = (needs to be=20 organized before the session),
  Agenda bashing (2 = minutes)

  Use of = mailing=20 lists,
  WG=20 status review (10 minutes)

  Current = charter=20 items:

    1. NETCONF=20 over TLS (20 minutes)

      =20 draft-ietf-netconf-tls-01.txt

    2.=20 Fine-grained locking (20 minutes)

      =20 draft-ietf-netconf-partial-lock-00.txt

    3. Netconf=20 monitoring (20 minutes)

      =20 draft-ietf-netconf-monitoring-00.txt

  Discussion = on ongoing=20 implementations (10 minutes)

     =20 Who is implementing what?
      Should we = plan an=20 interop-event for testing of
      RFC = 4141-4144 to get=20 them to DS?

  = AOB

  Open mike=20

     =20 One hot topic is e.g. the NETCONF-related requirements on DML.=20
      Any other hot topics to = discuss?=20

Note (this is not = part of the=20 agenda):
We are=20 not going to discuss solutions in open mic slot. =
This is just because we = have some time=20 and want to give
you the opportunity to sort out the NETCONF-related=20
requirements as=20 a preparation for the Canmod BoF. = =


------_=_NextPart_001_01C87FD3.B30BBFE4-- --===============1736431440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1736431440==-- From netconf-bounces@ietf.org Thu Mar 6 13:47:55 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772033A6E13; Thu, 6 Mar 2008 13:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.511 X-Spam-Level: X-Spam-Status: No, score=-100.511 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve8FS-t-+p3R; Thu, 6 Mar 2008 13:47:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C5E3A6A92; Thu, 6 Mar 2008 13:47:54 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D1C28C260 for ; Thu, 6 Mar 2008 13:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nKhNkGd0pJi for ; Thu, 6 Mar 2008 13:47:47 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 98AEA3A6E00 for ; Thu, 6 Mar 2008 13:47:46 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m26LlToi006559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 22:47:29 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m26LlR3i003130; Thu, 6 Mar 2008 22:47:29 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 22:47:26 +0100 MIME-Version: 1.0 Date: Thu, 6 Mar 2008 22:47:24 +0100 Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <004001c87fce$a6a682e0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach57gEuw6AQNNRaSNi7tZf5zkwv0AF1ngAAAAJ9bwAAAT+QUA== References: <004001c87fce$a6a682e0$0600a8c0@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext David B Harrington" , X-OriginalArrivalTime: 06 Mar 2008 21:47:26.0968 (UTC) FILETIME=[AB59DF80:01C87FD3] Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1736431440==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1736431440== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87FD3.B30BBFE4" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C87FD3.B30BBFE4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry about that, AC is meant to be "Access Control". =20 Cheers, Mehmet =20 ________________________________ From: ext David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Thursday, March 06, 2008 10:11 PM To: Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] Agenda for NETCONF WG session at IETF #71 =09 =09 Hi, =20 You use abbreviations in the agenda without spelling them out anywhere. What is AOB? I figured it out, but AC isn't spelled out anywhere. =20 dbh ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 06, 2008 3:02 PM To: netconf@ietf.org Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 =09 =09 Hi All, =20 I uploaded the agenda and WG status slides: =09 https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf =20 Presenters, please send me your slides prior to the=20 meeting. Thank you. =20 BTW: We still need minute takers ;-) =20 CU in Philly. Cheers, Mehmet =09 =20 ________________________________ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, February 28, 2008 10:41 AM To: netconf@ops.ietf.org Cc: ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) Subject: Agenda for NETCONF WG session at IETF #71 =09 =09 Dear NETCONF WG,=20 below is an update for the agenda of the NETCONF WG session=20 at the IETF #71.=20 Our main focus in the session will be on open issue discussion.=20 Please let us know before hand about your implementation.=20 Please let us also know whether you have a concrete topic for=20 the open mic session.=20 We still need volunteers as scribe and minute taker. As you=20 know the session will not start before we have them ;-).=20 Bert & Mehmet=20 _____________________________________________=20 NETCONF WG=20 IETF 71, Philadelphia, PA, USA=20 MONDAY, March 10, 2008 1740-1950=20 Scribes (needs to be organized before the session),=20 Agenda bashing (2 minutes)=20 Use of mailing lists,=20 WG status review (10 minutes)=20 Current charter items:=20 1. NETCONF over TLS (20 minutes)=20 draft-ietf-netconf-tls-01.txt=20 2. Fine-grained locking (20 minutes)=20 draft-ietf-netconf-partial-lock-00.txt=20 3. Netconf monitoring (20 minutes)=20 draft-ietf-netconf-monitoring-00.txt=20 Discussion on ongoing implementations (10 minutes)=20 Who is implementing what?=20 Should we plan an interop-event for testing of=20 RFC 4141-4144 to get them to DS?=20 AOB=20 Open mike=20 One hot topic is e.g. the NETCONF-related requirements on DML.=20 Any other hot topics to discuss?=20 Note (this is not part of the agenda):=20 We are not going to discuss solutions in open mic slot.=20 This is just because we have some time and want to give=20 you the opportunity to sort out the NETCONF-related=20 requirements as a preparation for the Canmod BoF.=20 ------_=_NextPart_001_01C87FD3.B30BBFE4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for NETCONF WG session at IETF #71
Sorry about that, AC is meant to be "Access=20 Control".
 
Cheers,
Mehmet
 

From: ext David B Harrington=20 [mailto:dbharrington@comcast.net]
Sent: Thursday, March 06, = 2008=20 10:11 PM
To: Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Subject: RE: [Netconf] Agenda for NETCONF = WG=20 session at IETF #71

Hi,
 
You use abbreviations in the agenda without = spelling them=20 out anywhere.
What is AOB?
I figured it out, but AC isn't spelled out=20 anywhere.
 
dbh

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Thursday, March 06, 2008 3:02 = PM
To:=20 netconf@ietf.org
Subject: Re: [Netconf] Agenda for NETCONF = WG=20 session at IETF #71

Hi All,
 
I uploaded the agenda and WG status=20 slides:
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Presenters, please send me your = slides=20 prior to the
meeting. Thank=20 you.
 
BTW: We still need minute takers=20 ;-)
 
CU in Philly.

Cheers,
Mehmet

 

From: = owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, = Mehmet=20 (NSN - DE/Muenich)
Sent: Thursday, February 28, 2008 = 10:41=20 AM
To: netconf@ops.ietf.org
Cc: ext Bert = Wijnen -=20 IETF; ext Romascanu, Dan (Dan)
Subject: Agenda for = NETCONF WG=20 session at IETF #71


Dear NETCONF = WG,=20

below is an = update for the=20 agenda of the NETCONF WG session
at the IETF #71.

Our main focus in = the session=20 will be on open issue discussion.
Please let us know before hand about your=20 implementation.
Please let us also know whether you have a concrete topic = for=20
the open mic=20 session.

We still need = volunteers as=20 scribe and minute taker. As you
know the session will not start before we = have them=20 ;-).

Bert & = Mehmet=20

_____________________________________________ =

NETCONF = WG=20
IETF 71, = Philadelphia, PA,=20 USA

MONDAY, March 10, = 2008=20 1740-1950

  Scribes = (needs to be=20 organized before the session),
  Agenda bashing (2 = minutes)

  Use of = mailing=20 lists,
  WG=20 status review (10 minutes)

  Current = charter=20 items:

    1. NETCONF=20 over TLS (20 minutes)

      =20 draft-ietf-netconf-tls-01.txt

    2.=20 Fine-grained locking (20 minutes)

      =20 draft-ietf-netconf-partial-lock-00.txt

    3. Netconf=20 monitoring (20 minutes)

      =20 draft-ietf-netconf-monitoring-00.txt

  Discussion = on ongoing=20 implementations (10 minutes)

     =20 Who is implementing what?
      Should we = plan an=20 interop-event for testing of
      RFC = 4141-4144 to get=20 them to DS?

  = AOB

  Open mike=20

     =20 One hot topic is e.g. the NETCONF-related requirements on DML.=20
      Any other hot topics to = discuss?=20

Note (this is not = part of the=20 agenda):
We are=20 not going to discuss solutions in open mic slot. =
This is just because we = have some time=20 and want to give
you the opportunity to sort out the NETCONF-related=20
requirements as=20 a preparation for the Canmod BoF. = =


------_=_NextPart_001_01C87FD3.B30BBFE4-- --===============1736431440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1736431440==-- From owner-netconf@ops.ietf.org Thu Mar 6 18:10:12 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0AE28C923 for ; Thu, 6 Mar 2008 18:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.34 X-Spam-Level: X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc9tM116FeNk for ; Thu, 6 Mar 2008 18:10:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4E753A6A72 for ; Thu, 6 Mar 2008 18:10:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXRqm-0004Xd-R5 for netconf-data@psg.com; Fri, 07 Mar 2008 01:58:20 +0000 Received: from [69.147.64.95] (helo=smtp122.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXRqj-0004X0-Nd for netconf@ops.ietf.org; Fri, 07 Mar 2008 01:58:19 +0000 Received: (qmail 20740 invoked from network); 7 Mar 2008 01:58:13 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.167.48 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 7 Mar 2008 01:58:13 -0000 X-YMail-OSG: 8Y9gcQkVM1n0uVxiFkhStjyq.pCAgZAI18LIUJvk7vU2DkkT X-Yahoo-Newman-Property: ymail-3 Message-ID: <47D0A134.2020208@andybierman.com> Date: Thu, 06 Mar 2008 17:58:12 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Muenich)" CC: netconf@ops.ietf.org, ext Bert Wijnen - IETF , "ext Romascanu, Dan (Dan)" Subject: Re: Agenda for NETCONF WG session at IETF #71 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Ersue, Mehmet (NSN - DE/Muenich) wrote: > > Dear NETCONF WG, > > below is an update for the agenda of the NETCONF WG session > at the IETF #71. > > Our main focus in the session will be on open issue discussion. > Please let us know before hand about your implementation. > Please let us also know whether you have a concrete topic for > the open mic session. > I have some running NETCONF code and a topic for the meeting, not that the 2 are related in any way... The WG agreed that the NETCONF Notifications work was not finished, and some standard notification content would really make the notification delivery features more relevant to our standardization efforts. Yet nothing has been done. What about a config-change event? When will any standard events for the NETCONF stream be defined? > We still need volunteers as scribe and minute taker. As you > know the session will not start before we have them ;-). > > Bert & Mehmet > Andy > _____________________________________________ > > NETCONF WG > IETF 71, Philadelphia, PA, USA > > MONDAY, March 10, 2008 1740-1950 > > Scribes (needs to be organized before the session), > Agenda bashing (2 minutes) > > Use of mailing lists, > WG status review (10 minutes) > > Current charter items: > > 1. NETCONF over TLS (20 minutes) > > draft-ietf-netconf-tls-01.txt > > 2. Fine-grained locking (20 minutes) > > draft-ietf-netconf-partial-lock-00.txt > > 3. Netconf monitoring (20 minutes) > > draft-ietf-netconf-monitoring-00.txt > > Discussion on ongoing implementations (10 minutes) > > Who is implementing what? > Should we plan an interop-event for testing of > RFC 4141-4144 to get them to DS? > > AOB > > Open mike > > One hot topic is e.g. the NETCONF-related requirements on DML. > Any other hot topics to discuss? > > Note (this is not part of the agenda): > We are not going to discuss solutions in open mic slot. > This is just because we have some time and want to give > you the opportunity to sort out the NETCONF-related > requirements as a preparation for the Canmod BoF. > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 7 02:57:54 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B5F3A6A2A for ; Fri, 7 Mar 2008 02:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.756 X-Spam-Level: X-Spam-Status: No, score=-0.756 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-qPuofiKkLz for ; Fri, 7 Mar 2008 02:57:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C31163A685B for ; Fri, 7 Mar 2008 02:57:53 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXa5y-0004NO-5c for netconf-data@psg.com; Fri, 07 Mar 2008 10:46:34 +0000 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXa5u-0004MZ-Mg for netconf@ops.ietf.org; Fri, 07 Mar 2008 10:46:32 +0000 X-IronPort-AV: E=Sophos;i="4.25,462,1199682000"; d="scan'208";a="96276400" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Mar 2008 05:46:27 -0500 X-IronPort-AV: E=Sophos;i="4.25,462,1199682000"; d="scan'208";a="165011212" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 07 Mar 2008 05:46:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Agenda for NETCONF WG session at IETF #71 Date: Fri, 7 Mar 2008 11:46:26 +0100 Message-ID: In-Reply-To: <47D0A134.2020208@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach/9rU+BAd6b36DTzON5N0iijiC5gASXkzw References: <47D0A134.2020208@andybierman.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Ersue, Mehmet (NSN - DE/Muenich)" Cc: , "ext Bert Wijnen - IETF" Sender: owner-netconf@ops.ietf.org Precedence: bulk =20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > What about a config-change event? > When will any standard events for the NETCONF stream be defined? >=20 >=20 This is certainly worth an Internet-Draft. I do not know when will NETCONF re-charter, and this may also be related to the DML discussions, but having a reference that more than one implementer will start to put in code will accelerate things.=20 Dan -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From netconf-bounces@ietf.org Fri Mar 7 03:57:24 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E3928C3DC; Fri, 7 Mar 2008 03:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.969 X-Spam-Level: X-Spam-Status: No, score=-99.969 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YgxlLHRiZNg; Fri, 7 Mar 2008 03:57:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644A53A6B74; Fri, 7 Mar 2008 03:57:21 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1591A3A6AF2 for ; Fri, 7 Mar 2008 03:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoVxCmU6Yh+C for ; Fri, 7 Mar 2008 03:57:16 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by core3.amsl.com (Postfix) with ESMTP id BF79C3A6A8C for ; Fri, 7 Mar 2008 03:57:15 -0800 (PST) Received: from mlsv16.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 964D537ACC for ; Fri, 7 Mar 2008 20:57:04 +0900 (JST) Received: from mfilter-s2.hitachi.co.jp by mlsv16.hitachi.co.jp (8.13.1/8.13.1) id m27Bv4xo017665; Fri, 7 Mar 2008 20:57:04 +0900 Received: from vshuts3.hitachi.co.jp (unverified) by mfilter-s2.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 7 Mar 2008 20:57:03 +0900 Received: from vshuts3.hitachi.co.jp (unknown [127.0.0.1]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 854B53925DB; Fri, 7 Mar 2008 20:57:03 +0900 (JST) X-AuditID: 0ac90648-aeb55ba000002a12-28-47d12d8f6f70 Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 5D5053925DC; Fri, 7 Mar 2008 20:57:03 +0900 (JST) Received: from localhost by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id m27Bv3d13652108; Fri, 7 Mar 2008 20:57:03 +0900 Date: Fri, 07 Mar 2008 20:57:01 +0900 (JST) Message-Id: <20080307.205701.56042190.hideki.okita.pf@hitachi.com> To: netconf@ietf.org From: OKITA Hideki In-Reply-To: <200802251545.m1PFjQEq069621@idle.juniper.net> References: <20080226.002814.195485559.hideki.okita.pf@hitachi.com> <200802251545.m1PFjQEq069621@idle.juniper.net> Organization: Central Research Lab., Hitachi Ltd., Japan X-Mailer: Mew version 5.2 on Emacs 22.0.90 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Mar_07_20_57_01_2008_022)--" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: shinji.nishimura.he@hitachi.com, markscot@nortel.com Subject: [Netconf] Schema advertisement draft updated (-01) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ----Next_Part(Fri_Mar_07_20_57_01_2008_022)-- Content-Type: TexFrom netconf-bounces@ietf.org Fri Mar 7 03:57:24 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E3928C3DC; Fri, 7 Mar 2008 03:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.969 X-Spam-Level: X-Spam-Status: No, score=-99.969 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YgxlLHRiZNg; Fri, 7 Mar 2008 03:57:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644A53A6B74; Fri, 7 Mar 2008 03:57:21 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1591A3A6AF2 for ; Fri, 7 Mar 2008 03:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoVxCmU6Yh+C for ; Fri, 7 Mar 2008 03:57:16 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by core3.amsl.com (Postfix) with ESMTP id BF79C3A6A8C for ; Fri, 7 Mar 2008 03:57:15 -0800 (PST) Received: from mlsv16.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 964D537ACC for ; Fri, 7 Mar 2008 20:57:04 +0900 (JST) Received: from mfilter-s2.hitachi.co.jp by mlsv16.hitachi.co.jp (8.13.1/8.13.1) id m27Bv4xo017665; Fri, 7 Mar 2008 20:57:04 +0900 Received: from vshuts3.hitachi.co.jp (unverified) by mfilter-s2.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 7 Mar 2008 20:57:03 +0900 Received: from vshuts3.hitachi.co.jp (unknown [127.0.0.1]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 854B53925DB; Fri, 7 Mar 2008 20:57:03 +0900 (JST) X-AuditID: 0ac90648-aeb55ba000002a12-28-47d12d8f6f70 Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 5D5053925DC; Fri, 7 Mar 2008 20:57:03 +0900 (JST) Received: from localhost by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id m27Bv3d13652108; Fri, 7 Mar 2008 20:57:03 +0900 Date: Fri, 07 Mar 2008 20:57:01 +0900 (JST) Message-Id: <20080307.205701.56042190.hideki.okita.pf@hitachi.com> To: netconf@ietf.org From: OKITA Hideki In-Reply-To: <200802251545.m1PFjQEq069621@idle.juniper.net> References: <20080226.002814.195485559.hideki.okita.pf@hitachi.com> <200802251545.m1PFjQEq069621@idle.juniper.net> Organization: Central Research Lab., Hitachi Ltd., Japan X-Mailer: Mew version 5.2 on Emacs 22.0.90 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Mar_07_20_57_01_2008_022)--" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: shinji.nishimura.he@hitachi.com, markscot@nortel.com Subject: [Netconf] Schema advertisement draft updated (-01) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ----Next_Part(Fri_Mar_07_20_57_01_2008_022)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello All, I have updated draft-okita-netconf-advertisement draft according to the comments from Martin, Balazs, Phil, and our chairs. I will submit this soon after the I-D tool restart on Monday. updated: - How each mapping transfer a WSDL file directly on its transport - How to describe a schema list in XSD style - How to add an original RPC Although this draft still includes following schema-query related solution for discussion in the Philadelphia, these items will be moved to -monitoring draft after next week. - How to describe supported datamodels in a XML document - How to describe a schema list in XSD style Regards, Hideki Okita ----Next_Part(Fri_Mar_07_20_57_01_2008_022)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: draft-okita-netconf-advertisement-01.txt Content-Disposition: inline; filename="draft-okita-netconf-advertisement-01.txt" Network Working Group H. Okita Internet-Draft Hitachi, Ltd. Intended status: Informational T. Iijima Expires: May 4, 2008 Y. Atarashi Alaxala Corp. November 2007 NETCONF Configuration Interface Advertisement with WSDL and XSD draft-okita-netconf-advertisement-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Okita, et al. Expires May 4, 2008 [Page 1] Internet-Draft NETCONF Interface Advertisement November 2007 Abstract This memo describes a configuration interface advertisement method for NETCONF device developers. In the proposal, the developers take a configuration interface definition information of target NETCONF devices. On their development environment, they generate stab classes to control the devices. The NETCONF device advertises their configuration interface by a WSDL file. The WSDL file describes message type of each NETCONF operation of the device. The WSDL file contains XML Schema in its types element and describes definition of the types definition used to configuration data. By this configuration interface advertisement, Network management System (NMS) developers can improve their development efficiency of the NMS. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. NETCONF Protocol . . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Target Architecture . . . . . . . . . . . . . . . . . . . 6 3.2. NETCONF Operation Interface Description by WSDL . . . . . 6 3.3. Operation and Datamodel Type Definition by XSD . . . . . . 9 3.4. Original RPC definitit/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello All, I have updated draft-okita-netconf-advertisement draft according to the comments from Martin, Balazs, Phil, and our chairs. I will submit this soon after the I-D tool restart on Monday. updated: - How each mapping transfer a WSDL file directly on its transport - How to describe a schema list in XSD style - How to add an original RPC Although this draft still includes following schema-query related solution for discussion in the Philadelphia, these items will be moved to -monitoring draft after next week. - How to describe supported datamodels in a XML document - How to describe a schema list in XSD style Regards, Hideki Okita ----Next_Part(Fri_Mar_07_20_57_01_2008_022)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: draft-okita-netconf-advertisement-01.txt Content-Disposition: inline; filename="draft-okita-netconf-advertisement-01.txt" Network Working Group H. Okita Internet-Draft Hitachi, Ltd. Intended status: Informational T. Iijima Expires: May 4, 2008 Y. Atarashi Alaxala Corp. November 2007 NETCONF Configuration Interface Advertisement with WSDL and XSD draft-okita-netconf-advertisement-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Okita, et al. Expires May 4, 2008 [Page 1] Internet-Draft NETCONF Interface Advertisement November 2007 Abstract This memo describes a configuration interface advertisement method for NETCONF device developers. In the proposal, the developers take a configuration interface definition information of target NETCONF devices. On their development environment, they generate stab classes to control the devices. The NETCONF device advertises their configuration interface by a WSDL file. The WSDL file describes message type of each NETCONF operation of the device. The WSDL file contains XML Schema in its types element and describes definition of the types definition used to configuration data. By this configuration interface advertisement, Network management System (NMS) developers can improve their development efficiency of the NMS. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. NETCONF Protocol . . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Target Architecture . . . . . . . . . . . . . . . . . . . 6 3.2. NETCONF Operation Interface Description by WSDL . . . . . 6 3.3. Operation and Datamodel Type Definition by XSD . . . . . . 9 3.4. Original RPC definition . . . . . . . . . . . . . . . . . 11 3.5. Schema list retrieval . . . . . . . . . . . . . . . . . . 12 3.6. Publishment of datamodels and interfaces information . . . 13 3.7. Reference Programming Model with Web-Service Middleware . 14 4. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Okita, et al. Expires May 4, 2008 [Page 2] Internet-Draft NETCONF Interface Advertisement November 2007 1. Introduction IETF netconf WG made up NETCONF protocol [1] , standard configuration protocol between a network management system and network devices. By using this unified management/configuration protocol, operators can reduce management/configuration cost. Now, the NETCONF protocol has a new additional requirement that NETCONF users would like to know configuration datamodels and interfaces supported by NETCONF devices. There are two situations, pre-deployment and post-deployment. In the pre-deployment case, software engineers would like to know NETCONF devices' datamodels and interfaces to develop their NMS. To implement the NETCONF NMS, the developers should check the Schema that defines the configuration data of the target NETCONF device. They should know XML tree construction of the configuration data and type definition of the each element in the XML tree. In the post-deployment case, a NETCONF client (manager) takes dinamically information about supported datamodels from a NETCONF server (device). For example, an operator applies a patch to a target NETCONF device to update supported datamodels from a NETCONF NMS, and check the update later. XML Schema [13] or other XML schema language is used to describe the structure of configuration data. NETCONF users can know supported datamodels by taking schemas from target devices. However, today there are no standard way to take the schema from a target NETCONF device. This document provides standard way to take information of datamodels and interfaces supported by a NETCONF device to improve NMS development process in the pre-deployment case. First, this document standardizes how to describe the configuration interface of NETCONF devices. Second, this document standardizes how to describe the type definition of the XML elements that occur in the NETCONF protocol messages. Last, this document standardizes how to advertise the above configuration interface definition information. This document also describe how NETCONF NMS developers automeate the construction of NETCONF stack during the development of a NETCONF NMS. Okita, et al. Expires May 4, 2008 [Page 3] Internet-Draft NETCONF Interface Advertisement November 2007 2. NETCONF Protocol Characteristics of the NETCONF protocol are (1) XML-format, (2) RPC- style, and (3) separation of operation and datamodel. The NETCONF protocol has protocol messages described in XML format. XML-format makes it easy for operators to read configuration data. It also improves machine readability of the configuration data since XML documents are well-formed. From a different viewpoint, various XML related tools eases development of devices compliant to the NETCONF protocol. The NETCONF protocol is a Remote Procedure Call (RPC) style protocol. RPC-style protocols have sets of a request message and a corresponding reply message. It is easy to implement on a management software, since each RPC of the protoon . . . . . . . . . . . . . . . . . 11 3.5. Schema list retrieval . . . . . . . . . . . . . . . . . . 12 3.6. Publishment of datamodels and interfaces information . . . 13 3.7. Reference Programming Model with Web-Service Middleware . 14 4. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Okita, et al. Expires May 4, 2008 [Page 2] Internet-Draft NETCONF Interface Advertisement November 2007 1. Introduction IETF netconf WG made up NETCONF protocol [1] , standard configuration protocol between a network management system and network devices. By using this unified management/configuration protocol, operators can reduce management/configuration cost. Now, the NETCONF protocol has a new additional requirement that NETCONF users would like to know configuration datamodels and interfaces supported by NETCONF devices. There are two situations, pre-deployment and post-deployment. In the pre-deployment case, software engineers would like to know NETCONF devices' datamodels and interfaces to develop their NMS. To implement the NETCONF NMS, the developers should check the Schema that defines the configuration data of the target NETCONF device. They should know XML tree construction of the configuration data and type definition of the each element in the XML tree. In the post-deployment case, a NETCONF client (manager) takes dinamically information about supported datamodels from a NETCONF server (device). For example, an operator applies a patch to a target NETCONF device to update supported datamodels from a NETCONF NMS, and check the update later. XML Schema [13] or other XML schema language is used to describe the structure of configuration data. NETCONF users can know supported datamodels by taking schemas from target devices. However, today there are no standard way to take the schema from a target NETCONF device. This document provides standard way to take information of datamodels and interfaces supported by a NETCONF device to improve NMS development process in the pre-deployment case. First, this document standardizes how to describe the configuration interface of NETCONF devices. Second, this document standardizes how to describe the type definition of the XML elements that occur in the NETCONF protocol messages. Last, this document standardizes how to advertise the above configuration interface definition information. This document also describe how NETCONF NMS developers automeate the construction of NETCONF stack during the development of a NETCONF NMS. Okita, et al. Expires May 4, 2008 [Page 3] Internet-Draft NETCONF Interface Advertisement November 2007 2. NETCONF Protocol Characteristics of the NETCONF protocol are (1) XML-format, (2) RPC- style, and (3) separation of operation and datamodel. The NETCONF protocol has protocol messages described in XML format. XML-format makes it easy for operators to read configuration data. It also improves machine readability of the configuration data since XML documents are well-formed. From a different viewpoint, various XML related tools eases development of devices compliant to the NETCONF protocol. The NETCONF protocol is a Remote Procedure Call (RPC) style protocol. RPC-style protocols have sets of a request message and a corresponding reply message. It is easy to implement on a management software, since each RPC of the protocol corresponds to a function call of the programs. Layer Example +-------------+ +-----------------------------+ (4) | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Transport | | SSH, SSL, console, | | Protocol | | SOAP/HTTP, BEEP | +-------------+ +-----------------------------+ Figure 1 The NETCONF protocol defines protocol operations and datamodels separately. The NETCONF protocol has four layers. Figure 1 shows the NETCONF protocol structure. It contains Transport Protocol Layer, RPC Layer, Operations Layer and Content Layer. In the RPC Layer and Operations Layer, the netconf WG defined RPC message and basic protocol operations [1] . These NETCONF operations carry configuration data inside element. The WG also Okita, et al. Expires May 4, 2008 [Page 4] Internet-Draft NETCONF Interface Advertisement November 2007 defined the transport mapping of the NETCONF protocol for SSH [2] , SOAP/HTTP [3] and BEEP [4] . The Content Layer defines model of the NETCONF content carried by NETCONF operations such as and . The structure of the configuration data is defined by schema language such as DTD [12] , XML Schema [13] or RelaxNG for the each model. Okita, et al. Expires May 4, 2008 [Page 5] Internet-Draft NETCONF Interface Advertisement November 2007 3. Proposal To fulfill the above requirements, we propose adoption of Web-Service architecture to the NETCONF system architecture. The proposed NETCONF system uses Web Service Description Language (WSDL) [16] and XML Schema (XSD) widely deployed in Web-service system. Features of this proposal: - WSDL for interface description - XSD for type definition - WSDL file transfer on mapping-depend transport with fixed URI 3.1. Target Architecture This proposal assumes the following NETCONF system architecture. Developers implement their NMS as a NETCONF manager on their development environment with help of the NETCONF configuration interface information provided by NETCONF device developers via the direct access to the NETCONF device or via indirect access with Web server. The implemented NMS works on a runtime environment and access NETCONF devices via NETCONF protocol. - NETCONF Device - Development Environment NETCONF Manager - Runtime Environment NETCONF Manager - Device vendor's Web server 3.2. NETCONF Operation Interface Description by WSDL NETCONF devices advertise their configuration interface to the NETCONF NMS developers. The developers know name of the operation, number and type of arguments, and type of return value from the interface advertisement. In this proposal, NETCONF system use WSDL file to advertise their configuration interface to the NMS developers. Somehow the NMS developers takes a WSDL file corresponding to a target NETCONF device, and read the WSDL file. Then the developers know NETCONF operations implemented in the NETCONF device. The WSDL file SHOULD include two ordinary NETCcol corresponds to a function call of the programs. Layer Example +-------------+ +-----------------------------+ (4) | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Transport | | SSH, SSL, console, | | Protocol | | SOAP/HTTP, BEEP | +-------------+ +-----------------------------+ Figure 1 The NETCONF protocol defines protocol operations and datamodels separately. The NETCONF protocol has four layers. Figure 1 shows the NETCONF protocol structure. It contains Transport Protocol Layer, RPC Layer, Operations Layer and Content Layer. In the RPC Layer and Operations Layer, the netconf WG defined RPC message and basic protocol operations [1] . These NETCONF operations carry configuration data inside element. The WG also Okita, et al. Expires May 4, 2008 [Page 4] Internet-Draft NETCONF Interface Advertisement November 2007 defined the transport mapping of the NETCONF protocol for SSH [2] , SOAP/HTTP [3] and BEEP [4] . The Content Layer defines model of the NETCONF content carried by NETCONF operations such as and . The structure of the configuration data is defined by schema language such as DTD [12] , XML Schema [13] or RelaxNG for the each model. Okita, et al. Expires May 4, 2008 [Page 5] Internet-Draft NETCONF Interface Advertisement November 2007 3. Proposal To fulfill the above requirements, we propose adoption of Web-Service architecture to the NETCONF system architecture. The proposed NETCONF system uses Web Service Description Language (WSDL) [16] and XML Schema (XSD) widely deployed in Web-service system. Features of this proposal: - WSDL for interface description - XSD for type definition - WSDL file transfer on mapping-depend transport with fixed URI 3.1. Target Architecture This proposal assumes the following NETCONF system architecture. Developers implement their NMS as a NETCONF manager on their development environment with help of the NETCONF configuration interface information provided by NETCONF device developers via the direct access to the NETCONF device or via indirect access with Web server. The implemented NMS works on a runtime environment and access NETCONF devices via NETCONF protocol. - NETCONF Device - Development Environment NETCONF Manager - Runtime Environment NETCONF Manager - Device vendor's Web server 3.2. NETCONF Operation Interface Description by WSDL NETCONF devices advertise their configuration interface to the NETCONF NMS developers. The developers know name of the operation, number and type of arguments, and type of return value from the interface advertisement. In this proposal, NETCONF system use WSDL file to advertise their configuration interface to the NMS developers. Somehow the NMS developers takes a WSDL file corresponding to a target NETCONF device, and read the WSDL file. Then the developers know NETCONF operations implemented in the NETCONF device. The WSDL file SHOULD include two ordinary NETCONF protocol message exchanges: hello exchange and RPC exchange. In the hello exchange, a Okita, et al. Expires May 4, 2008 [Page 6] Internet-Draft NETCONF Interface Advertisement November 2007 NETCONF Manager throws element to a NETCONF devices as a NETCONF request, and then get element from the NETCONF device as a NETCONF response. In the RPC exchange, the NETCONF manager throws element and get element. Below is a recommended WSDL file example to advertise NETCONF device configuration interface proposed in RFC4743. In this example, SOAP over HTTP is selected as its transport protocol binding. NETCONF device developers can choose their favorite transport binding and modify the binding part of this WSDL file. The WSDL file describes type definition of the argument and return value of each operation by XML Schema. Developers MAY prepare external XML Schema as separate file or inline Schema in this WSDL file. In this example, an external XML Schema defines the types. When developers prepare inline schema, they make types element under the definition element of this WSDL file and place schema element same with external schema under the types element. Okita, et al. Expires May 4, 2008 [Page 7] Internet-Draft NETCONF Interface Advertisement November 2007 When device developers choose SOAP over HTTP binding for the NETCONF configuration service, the WSDL ONF protocol message exchanges: hello exchange and RPC exchange. In the hello exchange, a Okita, et al. Expires May 4, 2008 [Page 6] Internet-Draft NETCONF Interface Advertisement November 2007 NETCONF Manager throws element to a NETCONF devices as a NETCONF request, and then get element from the NETCONF device as a NETCONF response. In the RPC exchange, the NETCONF manager throws element and get element. Below is a recommended WSDL file example to advertise NETCONF device configuration interface proposed in RFC4743. In this example, SOAP over HTTP is selected as its transport protocol binding. NETCONF device developers can choose their favorite transport binding and modify the binding part of this WSDL file. The WSDL file describes type definition of the argument and return value of each operation by XML Schema. Developers MAY prepare external XML Schema as separate file or inline Schema in this WSDL file. In this example, an external XML Schema defines the types. When developers prepare inline schema, they make types element under the definition element of this WSDL file and place schema element same with external schema under the types element. Okita, et al. Expires May 4, 2008 [Page 7] Internet-Draft NETCONF Interface Advertisement November 2007 When device developers choose SOAP over HTTP binding for the NETCONF configuration service, the WSDL file should select "document-literal" as its transport binding and message encoding. In the WSDL file, Okita, et al. Expires May 4, 2008 [Page 8] Internet-Draft NETCONF Interface Advertisement November 2007 style attribute of the binding element SHOULD be "document". input and output element in binding element SHOULD include body element that has attribute with "literal" value. 3.3. Operation and Datamodel Type Definition by XSD The NETCONF system should prepare XML Schema describing the type of argument and return value of rpc request. As described above, a WSDL file describes interface of a NETCONF device. In addition to the interface, the NETCONF device should advertise the type definition. The XSD file SHOULD include ordinary NETCONF operations described in NETCONF Protocol as the argument of rpc operation defined in the above WSDL file. The XSD file MAY also include NETCONF notification subscription operation described in NETCONF Notification [6] . The XSD file MAY also include additional NETCONF operations added by vendors. Ordinary NETCONF operations: - get - getConfig - editConfig - lock - unlock - subscribe NETCONF device developers can add configuration datamodel as additional type definition in this XSD file. They can add import element for the pointer to an external schema defining configuration item elements, for example, interfaceType, vlanType, and etc. They can use proposed configuration datamodels like VLAN datamodel [7] , Diff-Serv datamodel [8] , and ACL datamodel [9] . They can also include these type definitions as an inline schema in this XSD file. Following describes an example XML Schema advertising the type definition of the NETCONF operation messages. It contains following type definitions as an example. This XML Schema contains types for edit-config operation message, interface configuration message, and vlan configuration message. The two types are described by inline schema. Okita, et al. Expires May 4, 2008 [Page 9] Internet-Draft NETCONF Interface Advertisement November 2007 - rpcType - rpcOperationType - interfaceType - vlanType - configInlineType - editConfigType Okita, et al. Expires May 4, 2008 [Page 10] Internet-Draft NETCONF Interface Advertisement November 2007 Okita, et al. Expires May 4, 2008 [Page 10] Internet-Draft NETCONF Interface Advertisement November 2007 3.4. Original RPC definition NETCONF Protocol [1] defines standard NETCONF RPCs, get, get-config, edit-config, and so on. NETCONF device developers who would like to add a new original RPC should define new datatype used in this new RPC transaction. The developers should define the datatype as the extension of rpcOperationType, which represents abstracted RPC operation datatype that placed in the element. Okita, et al. Expires May 4, 2008 [Page 11] Internet-Draft NETCONF Interface Advertisement November 2007 Following example is a definition of a new Reset operation that uses element in element without child element. Since RPC operations are abstracted to rpcOperationType, the developers have only to define extended datatype. 3.5. Schema list retrieval In the post-deployment phase, there is an another requirement that users would like to retrieve only the list of supported configuration datamodels on a NETCONF device. In this requirement, users do not require the body of the schemas describing the datamodels. For this requirement, importing external schema into a WSDL file would be a solution. To avoid schema body, the WSDL describing datamodels and interfaces of a NETCONF device MAY contain external reference in its element. Each reference is described by element that have each namespace and schemaLocation attribute. The schemaLocation attribute represents its actual location. Okita, et al. Expires May 4, 2008 [Page 12] Internet-Draft NETCONF Interface Advertisement November 2007 (Operation definitions) 3.6. Publishment of datamodels and interfaces information NETCONF device developers can publish the device's datamodels and interfaces described by WSDL and XSD by several methods as described below. Datastore on a target NETCONF device HTTP or FTP server on a vendor's Web site. Paper document for NMS developers NETCONF device SHOULD use each transport protocol to transfer datamodels and interfaces information. In the pre-deployment case, users take theType for element --> 3.4. Original RPC definition NETCONF Protocol [1] defines standard NETCONF RPCs, get, get-config, edit-config, and so on. NETCONF device developers who would like to add a new original RPC should define new datatype used in this new RPC transaction. The developers should define the datatype as the extension of rpcOperationType, which represents abstracted RPC operation datatype that placed in the element. Okita, et al. Expires May 4, 2008 [Page 11] Internet-Draft NETCONF Interface Advertisement November 2007 Following example is a definition of a new Reset operation that uses element in element without child element. Since RPC operations are abstracted to rpcOperationType, the developers have only to define extended datatype. 3.5. Schema list retrieval In the post-deployment phase, there is an another requirement that users would like to retrieve only the list of supported configuration datamodels on a NETCONF device. In this requirement, users do not require the body of the schemas describing the datamodels. For this requirement, importing external schema into a WSDL file would be a solution. To avoid schema body, the WSDL describing datamodels and interfaces of a NETCONF device MAY contain external reference in its element. Each reference is described by element that have each namespace and schemaLocation attribute. The schemaLocation attribute represents its actual location. Okita, et al. Expires May 4, 2008 [Page 12] Internet-Draft NETCONF Interface Advertisement November 2007 (Operation definitions) 3.6. Publishment of datamodels and interfaces information NETCONF device developers can publish the device's datamodels and interfaces described by WSDL and XSD by several methods as described below. Datastore on a target NETCONF device HTTP or FTP server on a vendor's Web site. Paper document for NMS developers NETCONF device SHOULD use each transport protocol to transfer datamodels and interfaces information. In the pre-deployment case, users take the configuration information through their development environments. These development environments do not necessarily have NETCONF features. A NETCONF device cannot presuppose existence of the NETCONF session. For example, Web-Service development environments normally use HTTP to take service information described by WSDL and XSD. The NETCONF device that supports SSH mapping MUST store a WSDL file on its SFTP datastore related to an published URI. It MUST transfer the WSDL file on a SFTP session for a request to the URI from the NETCONF device. Following is an example URI for the WSDL file on SFTP tree. Okita, et al. Expires May 4, 2008 [Page 13] Internet-Draft NETCONF Interface Advertisement November 2007 sftp://netconf.device/netconf.wsdl The NETCONF device that supports SOAP/HTTP mapping MUST store a WSDL file on its HTTP datastore related to an published URI. It MUST transfer the WSDL file on a HTTP session for a request to the URI from the NETCONF device. Following is an example URI for the WSDL file on HTTP tree. http://netconf.device/netconf.wsdl (TBD) The NETCONF device that supports BEEP mapping MUST transfer a WSDL file on the BEEP channel that supports file transfer mechanism. SOAP/BEEP [11] could be a solution. 3.7. Reference Programming Model with Web-Service Middleware When a NETCONF device support NETCONF over SOAP and publish its WSDL, NMS developers can reduce much of their implementation time. They can utilize Web-Service middleware to construct their NMS code. From the WSDL file published by the NETCONF device, the Web-Service middleware generate automatically stub classes for NMS code to access configuration interface of the NETCONF device via SOAP over HTTP transport. The NMS developers have only to implement NMS logic using the stub classes. Using WSDL and Web-Service middleware, NMS developers might follow the sequence described below. - prepare a NETCONF device - take a WSDL file from the device via HTTP - extract XML Schema from the WSDL file for reference - generate stub class source file from the WSDL file by Web- Service middleware - take the stub class in their development environment Okita, et al. Expires May 4, 2008 [Page 14] Internet-Draft NETCONF Interface Advertisement November 2007 4. Security Consideration In the NETCONF architecture, the transport protocol layer is responsible for the security between a network manager and network devices. Okita, et al. Expires May 4, 2008 [Page 15] Internet-Draft NETCONF Interface Advertisement November 2007 5. IANA Consideration This document has no actions for IANA. Okita, et al. Expires May 4, 2008 [Page 16] Internet-Draft NETCONF Interface Advertisement November 2007 6. References 6.1. Normative References [1] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [2] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006. [3] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006. [4] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006. 6.2. Informative References [5] Chisholm, S. and A. Clemm, "Using XML Schema to define NETCONF Content", draft-chisholm-netconf-model-08 (work in progress), February 2008. [6] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", draft-ietf-netconf-notification-12 (work in progress), February 2008. [7] Iijima, T., "VLAN data model for configuration information through their development environments. These development environments do not necessarily have NETCONF features. A NETCONF device cannot presuppose existence of the NETCONF session. For example, Web-Service development environments normally use HTTP to take service information described by WSDL and XSD. The NETCONF device that supports SSH mapping MUST store a WSDL file on its SFTP datastore related to an published URI. It MUST transfer the WSDL file on a SFTP session for a request to the URI from the NETCONF device. Following is an example URI for the WSDL file on SFTP tree. Okita, et al. Expires May 4, 2008 [Page 13] Internet-Draft NETCONF Interface Advertisement November 2007 sftp://netconf.device/netconf.wsdl The NETCONF device that supports SOAP/HTTP mapping MUST store a WSDL file on its HTTP datastore related to an published URI. It MUST transfer the WSDL file on a HTTP session for a request to the URI from the NETCONF device. Following is an example URI for the WSDL file on HTTP tree. http://netconf.device/netconf.wsdl (TBD) The NETCONF device that supports BEEP mapping MUST transfer a WSDL file on the BEEP channel that supports file transfer mechanism. SOAP/BEEP [11] could be a solution. 3.7. Reference Programming Model with Web-Service Middleware When a NETCONF device support NETCONF over SOAP and publish its WSDL, NMS developers can reduce much of their implementation time. They can utilize Web-Service middleware to construct their NMS code. From the WSDL file published by the NETCONF device, the Web-Service middleware generate automatically stub classes for NMS code to access configuration interface of the NETCONF device via SOAP over HTTP transport. The NMS developers have only to implement NMS logic using the stub classes. Using WSDL and Web-Service middleware, NMS developers might follow the sequence described below. - prepare a NETCONF device - take a WSDL file from the device via HTTP - extract XML Schema from the WSDL file for reference - generate stub class source file from the WSDL file by Web- Service middleware - take the stub class in their development environment Okita, et al. Expires May 4, 2008 [Page 14] Internet-Draft NETCONF Interface Advertisement November 2007 4. Security Consideration In the NETCONF architecture, the transport protocol layer is responsible for the security between a network manager and network devices. Okita, et al. Expires May 4, 2008 [Page 15] Internet-Draft NETCONF Interface Advertisement November 2007 5. IANA Consideration This document has no actions for IANA. Okita, et al. Expires May 4, 2008 [Page 16] Internet-Draft NETCONF Interface Advertisement November 2007 6. References 6.1. Normative References [1] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [2] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006. [3] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006. [4] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006. 6.2. Informative References [5] Chisholm, S. and A. Clemm, "Using XML Schema to define NETCONF Content", draft-chisholm-netconf-model-08 (work in progress), February 2008. [6] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", draft-ietf-netconf-notification-12 (work in progress), February 2008. [7] Iijima, T., "VLAN data model for NETCONF", draft-iijima-ngo-vlandatamodel-01 (work in progress), August 2007. [8] Okita, H., "A NETCONF Datamodel for Diff-Serv QoS Control Configuration", draft-okita-ngo-diffservdatamodel-01 (work in progress), July 2007. [9] Tomoyuki, I., Atarashi, Y., Kimura, H., Kitani, M., and H. Okita, "ACL data model for NETCONF", draft-iijima-ngo-acldatamodel-01 (work in progress), December 2007. [10] Tomoyuki, I., Atarashi, Y., Kimura, H., Kitani, M., and H. Okita, "Experience of implementing NETCONF over SOAP", draft-iijima-netconf-soap-implementation-06 (work in progress), February 2008. [11] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3288, June 2002. Okita, et al. Expires May 4, 2008 [Page 17] Internet-Draft NETCONF Interface Advertisement November 2007 [12] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, . [13] Fallside, D., "XML Schema Part 0: Primer", World Wide Web Consortium FirstEdition REC-xmlschema-0-20010502, May 2001, . [14] Gudgin, M., Hadley, M., Moreau, J., Mendelsohn, N., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium FirstEdition REC-soap12-part1-20030624, June 2003, . [15] Booth, D. and C. Liu, "Web Services Description Language (WSDL) Version 2.0 Part 0: Primer", World Wide Web Consortium Recommendation REC-wsdl20-primer-20070626, June 2007, . [16] Chinnici, R., Ryman, A., Moreau, J., and S. Weerawarana, "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language", World Wide Web Consortium Recommendation REC-wsdl20- 20070626, June 2007, . [17] Haas, H., Moreau, J., Weerawarana, S., Lewis, A., Orchard, D., and R. Chinnici, "Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts", World Wide Web Consortium Recommendation REC-wsdl20-adjuncts-20070626, June 2007, . Okita, et al. Expires May 4, 2008 [Page 18] Internet-Draft NETCONF Interface Advertisement November 2007 Authors' Addresses Hideki Okita Central Research Laboratory, Hitachi, Ltd. 1-280 Higashi-Koigakubo Kokubunji, Tokyo 185-8601 Japan Phone: +81-42-323-1111 Fax: +81-42-327-7868 Email: hideki.okita.pf@hitachi.com Tomoyuki Iijima Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: tomoyuki.iijima@alaxala.com Yoshifumi Atarashi Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: atarashi@alaxala.net Okita, et al. Expires May 4, 2008 [Page 19] Internet-Draft NETCONF Interface Advertisement November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THNETCONF", draft-iijima-ngo-vlandatamodel-01 (work in progress), August 2007. [8] Okita, H., "A NETCONF Datamodel for Diff-Serv QoS Control Configuration", draft-okita-ngo-diffservdatamodel-01 (work in progress), July 2007. [9] Tomoyuki, I., Atarashi, Y., Kimura, H., Kitani, M., and H. Okita, "ACL data model for NETCONF", draft-iijima-ngo-acldatamodel-01 (work in progress), December 2007. [10] Tomoyuki, I., Atarashi, Y., Kimura, H., Kitani, M., and H. Okita, "Experience of implementing NETCONF over SOAP", draft-iijima-netconf-soap-implementation-06 (work in progress), February 2008. [11] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3288, June 2002. Okita, et al. Expires May 4, 2008 [Page 17] Internet-Draft NETCONF Interface Advertisement November 2007 [12] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, . [13] Fallside, D., "XML Schema Part 0: Primer", World Wide Web Consortium FirstEdition REC-xmlschema-0-20010502, May 2001, . [14] Gudgin, M., Hadley, M., Moreau, J., Mendelsohn, N., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium FirstEdition REC-soap12-part1-20030624, June 2003, . [15] Booth, D. and C. Liu, "Web Services Description Language (WSDL) Version 2.0 Part 0: Primer", World Wide Web Consortium Recommendation REC-wsdl20-primer-20070626, June 2007, . [16] Chinnici, R., Ryman, A., Moreau, J., and S. Weerawarana, "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language", World Wide Web Consortium Recommendation REC-wsdl20- 20070626, June 2007, . [17] Haas, H., Moreau, J., Weerawarana, S., Lewis, A., Orchard, D., and R. Chinnici, "Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts", World Wide Web Consortium Recommendation REC-wsdl20-adjuncts-20070626, June 2007, . Okita, et al. Expires May 4, 2008 [Page 18] Internet-Draft NETCONF Interface Advertisement November 2007 Authors' Addresses Hideki Okita Central Research Laboratory, Hitachi, Ltd. 1-280 Higashi-Koigakubo Kokubunji, Tokyo 185-8601 Japan Phone: +81-42-323-1111 Fax: +81-42-327-7868 Email: hideki.okita.pf@hitachi.com Tomoyuki Iijima Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: tomoyuki.iijima@alaxala.com Yoshifumi Atarashi Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: atarashi@alaxala.net Okita, et al. Expires May 4, 2008 [Page 19] Internet-Draft NETCONF Interface Advertisement November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Okita, et al. Expires May 4, 2008 [Page 20] ----Next_Part(Fri_Mar_07_20_57_01_2008_022)-- Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ----Next_Part(Fri_Mar_07_20_57_01_2008_022)---- E ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Okita, et al. Expires May 4, 2008 [Page 20] ----Next_Part(Fri_Mar_07_20_57_01_2008_022)-- Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ----Next_Part(Fri_Mar_07_20_57_01_2008_022)---- From netconf-bounces@ietf.org Fri Mar 7 11:51:06 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0859128C138; Fri, 7 Mar 2008 11:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.901 X-Spam-Level: X-Spam-Status: No, score=-99.901 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJXmB6dya5Yx; Fri, 7 Mar 2008 11:51:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2454C28CA43; Fri, 7 Mar 2008 11:50:45 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A9928C412 for ; Fri, 7 Mar 2008 11:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUCcBobTPxmz for ; Fri, 7 Mar 2008 11:50:42 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 618893A680C for ; Fri, 7 Mar 2008 11:50:15 -0800 (PST) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id yBj51Y0080vp7WLA70RC00; Fri, 07 Mar 2008 19:49:19 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id yKnN1Y0044HwxpC8R00000; Fri, 07 Mar 2008 19:47:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=ogM6KDja5iMA:10 a=48vgC7mUAAAA:8 a=k-7ecQdfAwIaJNP_oTUA:9 a=w6-0Zhc1zr-v4fhdXJsA:7 a=5Cg1rYQYNUQn1lKsCgGF9EV7t3AA:4 a=zwC7bnKO5xoA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=kwz2ALlf93kA:10 a=lGaHI92pyL9AdXFIv4cA:9 a=S7B7PXQ2Cvw9Isow8nQA:7 a=gfj-AscacUgLSAkbd0ymI4E8nGYA:4 a=AfD3MYMu9mQA:10 From: "David B Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: <004001c87fce$a6a682e0$0600a8c0@china.huawei.com> Date: Fri, 7 Mar 2008 14:47:21 -0500 Message-ID: <009001c8808c$1013f7e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Ach57gEuw6AQNNRaSNi7tZf5zkwv0AF1ngAAAAJ9bwAAAT+QUAAuJ1WA Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0381944015==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0381944015== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01C88062.273DEFE0" This is a multi-part message in MIME format. ------=_NextPart_000_0091_01C88062.273DEFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit and what is AOB? _____ From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] Sent: Thursday, March 06, 2008 4:47 PM To: ext David B Harrington; netconf@ietf.org Subject: RE: [Netconf] Agenda for NETCONF WG session at IETF #71 Sorry about that, AC is meant to be "Access Control". Cheers, Mehmet _____ From: ext David B Harrington [mailto:dbharrington@comcast.net] Sent: Thursday, March 06, 2008 10:11 PM To: Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] Agenda for NETCONF WG session at IETF #71 Hi, You use abbreviations in the agenda without spelling them out anywhere. What is AOB? I figured it out, but AC isn't spelled out anywhere. dbh _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 06, 2008 3:02 PM To: netconf@ietf.org Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 Hi All, I uploaded the agenda and WG status slides: https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf Presenters, please send me your slides prior to the meeting. Thank you. BTW: We still need minute takers ;-) CU in Philly. Cheers, Mehmet _____ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, February 28, 2008 10:41 AM To: netconf@ops.ietf.org Cc: ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) Subject: Agenda for NETCONF WG session at IETF #71 Dear NETCONF WG, below is an update for the agenda of the NETCONF WG session at the IETF #71. Our main focus in the session will be on open issue discussion. Please let us know before hand about your implementation. Please let us also know whether you have a concrete topic for the open mic session. We still need volunteers as scribe and minute taker. As you know the session will not start before we have them ;-). Bert & Mehmet _____________________________________________ NETCONF WG IETF 71, Philadelphia, PA, USA MONDAY, March 10, 2008 1740-1950 Scribes (needs to be organized before the session), Agenda bashing (2 minutes) Use of mailing lists, WG status review (10 minutes) Current charter items: 1. NETCONF over TLS (20 minutes) draft-ietf-netconf-tls-01.txt 2. Fine-grained locking (20 minutes) draft-ietf-netconf-partial-lock-00.txt 3. Netconf monitoring (20 minutes) draft-ietf-netconf-monitoring-00.txt Discussion on ongoing implementations (10 minutes) Who is implementing what? Should we plan an interop-event for testing of RFC 4141-4144 to get them to DS? AOB Open mike One hot topic is e.g. the NETCONF-related requirements on DML. Any other hot topics to discuss? Note (this is not part of the agenda): We are not going to discuss solutions in open mic slot. This is just because we have some time and want to give you the opportunity to sort out the NETCONF-related requirements as a preparation for the Canmod BoF. ------=_NextPart_000_0091_01C88062.273DEFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for NETCONF WG session at IETF #71
and what is AOB?

From: Ersue, Mehmet (NSN - = DE/Muenich)=20 [mailto:mehmet.ersue@nsn.com]
Sent: Thursday, March 06, = 2008 4:47=20 PM
To: ext David B Harrington; = netconf@ietf.org
Subject:=20 RE: [Netconf] Agenda for NETCONF WG session at IETF = #71

Sorry about that, AC is meant to be "Access=20 Control".
 
Cheers,
Mehmet
 

From: ext David B Harrington=20 [mailto:dbharrington@comcast.net]
Sent: Thursday, March = 06, 2008=20 10:11 PM
To: Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Subject: RE: [Netconf] Agenda for NETCONF = WG=20 session at IETF #71

Hi,
 
You use abbreviations in the agenda without = spelling=20 them out anywhere.
What is AOB?
I figured it out, but AC isn't spelled out=20 anywhere.
 
dbh

From: netconf-bounces@ietf.org = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = Mehmet (NSN -=20 DE/Muenich)
Sent: Thursday, March 06, 2008 3:02 = PM
To:=20 netconf@ietf.org
Subject: Re: [Netconf] Agenda for = NETCONF WG=20 session at IETF #71

Hi All,
 
I uploaded the agenda and WG status=20 slides:
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Presenters, please send me your=20 slides prior to the =
meeting. Thank=20 you.
 
BTW: We still need minute takers=20 ;-)
 
CU in Philly.

Cheers,
Mehmet

 

From: = owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext = Ersue,=20 Mehmet (NSN - DE/Muenich)
Sent: Thursday, February 28, = 2008=20 10:41 AM
To: netconf@ops.ietf.org
Cc: ext = Bert=20 Wijnen - IETF; ext Romascanu, Dan (Dan)
Subject: = Agenda for=20 NETCONF WG session at IETF #71


Dear NETCONF=20 WG,

below is an = update for the=20 agenda of the NETCONF WG session
at the IETF #71.

Our main focus = in the session=20 will be on open issue discussion.
Please let us know before hand about = your=20 implementation.
Please let us also know whether you have a concrete = topic for=20
the open mic=20 session.

We still need = volunteers as=20 scribe and minute taker. As you
know the session will not start before = we have them=20 ;-).

Bert &=20 Mehmet

_____________________________________________ =

NETCONF = WG=20
IETF 71, = Philadelphia, PA,=20 USA

MONDAY, March = 10, 2008=20 1740-1950

  Scribes = (needs to be=20 organized before the session),
  Agenda bashing (2 = minutes)

  Use of = mailing=20 lists,
 =20 WG status review (10 minutes)

  Current = charter=20 items:

    1. NETCONF=20 over TLS (20 minutes)

      =20 draft-ietf-netconf-tls-01.txt

    2.=20 Fine-grained locking (20 minutes)

      =20 draft-ietf-netconf-partial-lock-00.txt

    3. Netconf=20 monitoring (20 minutes)

      =20 draft-ietf-netconf-monitoring-00.txt

  = Discussion on ongoing=20 implementations (10 minutes)

      Who is implementing=20 what?
      Should we plan an = interop-event=20 for testing of
      RFC 4141-4144 to get = them to DS?=20

  = AOB

  Open = mike=20

      One hot topic is e.g. = the=20 NETCONF-related requirements on DML.
      Any=20 other hot topics to discuss?

Note (this is = not part of the=20 agenda):
We=20 are not going to discuss solutions in open mic slot.=20
This is just=20 because we have some time and want to give =
you the opportunity to = sort out the=20 NETCONF-related
requirements as a preparation for the Canmod=20 BoF.=20 =


------=_NextPart_000_0091_01C88062.273DEFE0-- --===============0381944015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0381944015==-- From netconf-bounces@ietf.org Fri Mar 7 11:51:06 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0859128C138; Fri, 7 Mar 2008 11:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.901 X-Spam-Level: X-Spam-Status: No, score=-99.901 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJXmB6dya5Yx; Fri, 7 Mar 2008 11:51:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2454C28CA43; Fri, 7 Mar 2008 11:50:45 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A9928C412 for ; Fri, 7 Mar 2008 11:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUCcBobTPxmz for ; Fri, 7 Mar 2008 11:50:42 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 618893A680C for ; Fri, 7 Mar 2008 11:50:15 -0800 (PST) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id yBj51Y0080vp7WLA70RC00; Fri, 07 Mar 2008 19:49:19 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id yKnN1Y0044HwxpC8R00000; Fri, 07 Mar 2008 19:47:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=ogM6KDja5iMA:10 a=48vgC7mUAAAA:8 a=k-7ecQdfAwIaJNP_oTUA:9 a=w6-0Zhc1zr-v4fhdXJsA:7 a=5Cg1rYQYNUQn1lKsCgGF9EV7t3AA:4 a=zwC7bnKO5xoA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=kwz2ALlf93kA:10 a=lGaHI92pyL9AdXFIv4cA:9 a=S7B7PXQ2Cvw9Isow8nQA:7 a=gfj-AscacUgLSAkbd0ymI4E8nGYA:4 a=AfD3MYMu9mQA:10 From: "David B Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: <004001c87fce$a6a682e0$0600a8c0@china.huawei.com> Date: Fri, 7 Mar 2008 14:47:21 -0500 Message-ID: <009001c8808c$1013f7e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Ach57gEuw6AQNNRaSNi7tZf5zkwv0AF1ngAAAAJ9bwAAAT+QUAAuJ1WA Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0381944015==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0381944015== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01C88062.273DEFE0" This is a multi-part message in MIME format. ------=_NextPart_000_0091_01C88062.273DEFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit and what is AOB? _____ From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] Sent: Thursday, March 06, 2008 4:47 PM To: ext David B Harrington; netconf@ietf.org Subject: RE: [Netconf] Agenda for NETCONF WG session at IETF #71 Sorry about that, AC is meant to be "Access Control". Cheers, Mehmet _____ From: ext David B Harrington [mailto:dbharrington@comcast.net] Sent: Thursday, March 06, 2008 10:11 PM To: Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] Agenda for NETCONF WG session at IETF #71 Hi, You use abbreviations in the agenda without spelling them out anywhere. What is AOB? I figured it out, but AC isn't spelled out anywhere. dbh _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 06, 2008 3:02 PM To: netconf@ietf.org Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 Hi All, I uploaded the agenda and WG status slides: https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf Presenters, please send me your slides prior to the meeting. Thank you. BTW: We still need minute takers ;-) CU in Philly. Cheers, Mehmet _____ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, February 28, 2008 10:41 AM To: netconf@ops.ietf.org Cc: ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) Subject: Agenda for NETCONF WG session at IETF #71 Dear NETCONF WG, below is an update for the agenda of the NETCONF WG session at the IETF #71. Our main focus in the session will be on open issue discussion. Please let us know before hand about your implementation. Please let us also know whether you have a concrete topic for the open mic session. We still need volunteers as scribe and minute taker. As you know the session will not start before we have them ;-). Bert & Mehmet _____________________________________________ NETCONF WG IETF 71, Philadelphia, PA, USA MONDAY, March 10, 2008 1740-1950 Scribes (needs to be organized before the session), Agenda bashing (2 minutes) Use of mailing lists, WG status review (10 minutes) Current charter items: 1. NETCONF over TLS (20 minutes) draft-ietf-netconf-tls-01.txt 2. Fine-grained locking (20 minutes) draft-ietf-netconf-partial-lock-00.txt 3. Netconf monitoring (20 minutes) draft-ietf-netconf-monitoring-00.txt Discussion on ongoing implementations (10 minutes) Who is implementing what? Should we plan an interop-event for testing of RFC 4141-4144 to get them to DS? AOB Open mike One hot topic is e.g. the NETCONF-related requirements on DML. Any other hot topics to discuss? Note (this is not part of the agenda): We are not going to discuss solutions in open mic slot. This is just because we have some time and want to give you the opportunity to sort out the NETCONF-related requirements as a preparation for the Canmod BoF. ------=_NextPart_000_0091_01C88062.273DEFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for NETCONF WG session at IETF #71
and what is AOB?

From: Ersue, Mehmet (NSN - = DE/Muenich)=20 [mailto:mehmet.ersue@nsn.com]
Sent: Thursday, March 06, = 2008 4:47=20 PM
To: ext David B Harrington; = netconf@ietf.org
Subject:=20 RE: [Netconf] Agenda for NETCONF WG session at IETF = #71

Sorry about that, AC is meant to be "Access=20 Control".
 
Cheers,
Mehmet
 

From: ext David B Harrington=20 [mailto:dbharrington@comcast.net]
Sent: Thursday, March = 06, 2008=20 10:11 PM
To: Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Subject: RE: [Netconf] Agenda for NETCONF = WG=20 session at IETF #71

Hi,
 
You use abbreviations in the agenda without = spelling=20 them out anywhere.
What is AOB?
I figured it out, but AC isn't spelled out=20 anywhere.
 
dbh

From: netconf-bounces@ietf.org = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = Mehmet (NSN -=20 DE/Muenich)
Sent: Thursday, March 06, 2008 3:02 = PM
To:=20 netconf@ietf.org
Subject: Re: [Netconf] Agenda for = NETCONF WG=20 session at IETF #71

Hi All,
 
I uploaded the agenda and WG status=20 slides:
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Presenters, please send me your=20 slides prior to the =
meeting. Thank=20 you.
 
BTW: We still need minute takers=20 ;-)
 
CU in Philly.

Cheers,
Mehmet

 

From: = owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext = Ersue,=20 Mehmet (NSN - DE/Muenich)
Sent: Thursday, February 28, = 2008=20 10:41 AM
To: netconf@ops.ietf.org
Cc: ext = Bert=20 Wijnen - IETF; ext Romascanu, Dan (Dan)
Subject: = Agenda for=20 NETCONF WG session at IETF #71


Dear NETCONF=20 WG,

below is an = update for the=20 agenda of the NETCONF WG session
at the IETF #71.

Our main focus = in the session=20 will be on open issue discussion.
Please let us know before hand about = your=20 implementation.
Please let us also know whether you have a concrete = topic for=20
the open mic=20 session.

We still need = volunteers as=20 scribe and minute taker. As you
know the session will not start before = we have them=20 ;-).

Bert &=20 Mehmet

_____________________________________________ =

NETCONF = WG=20
IETF 71, = Philadelphia, PA,=20 USA

MONDAY, March = 10, 2008=20 1740-1950

  Scribes = (needs to be=20 organized before the session),
  Agenda bashing (2 = minutes)

  Use of = mailing=20 lists,
 =20 WG status review (10 minutes)

  Current = charter=20 items:

    1. NETCONF=20 over TLS (20 minutes)

      =20 draft-ietf-netconf-tls-01.txt

    2.=20 Fine-grained locking (20 minutes)

      =20 draft-ietf-netconf-partial-lock-00.txt

    3. Netconf=20 monitoring (20 minutes)

      =20 draft-ietf-netconf-monitoring-00.txt

  = Discussion on ongoing=20 implementations (10 minutes)

      Who is implementing=20 what?
      Should we plan an = interop-event=20 for testing of
      RFC 4141-4144 to get = them to DS?=20

  = AOB

  Open = mike=20

      One hot topic is e.g. = the=20 NETCONF-related requirements on DML.
      Any=20 other hot topics to discuss?

Note (this is = not part of the=20 agenda):
We=20 are not going to discuss solutions in open mic slot.=20
This is just=20 because we have some time and want to give =
you the opportunity to = sort out the=20 NETCONF-related
requirements as a preparation for the Canmod=20 BoF.=20 =


------=_NextPart_000_0091_01C88062.273DEFE0-- --===============0381944015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0381944015==-- From netconf-bounces@ietf.org Sat Mar 8 06:22:40 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9229328D6A9; Sat, 8 Mar 2008 06:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.896 X-Spam-Level: X-Spam-Status: No, score=-99.896 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq2NL3LbwxbY; Sat, 8 Mar 2008 06:22:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439C028CA9B; Sat, 8 Mar 2008 06:01:48 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4811728E1AA for ; Sat, 8 Mar 2008 06:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQwF6vjPkV+0 for ; Sat, 8 Mar 2008 06:01:44 -0800 (PST) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id D76BC28CFB0 for ; Fri, 7 Mar 2008 12:20:47 -0800 (PST) Received: (qmail 50576 invoked from network); 7 Mar 2008 20:20:35 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 7 Mar 2008 20:20:35 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , Date: Fri, 7 Mar 2008 21:20:42 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <009001c8808c$1013f7e0$0600a8c0@china.huawei.com> Importance: Normal Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0196709585==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0196709585== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0393_01C88099.198C35F0" This is a multi-part message in MIME format. ------=_NextPart_000_0393_01C88099.198C35F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Agenda for NETCONF WG session at IETF #71Any Other Businesss (of course). I thought this is a pretty well known acronym for meeting agendas, no? Bert Wijnen -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David B Harrington Verzonden: vrijdag 7 maart 2008 20:47 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 and what is AOB? ---------------------------------------------------------------------------- From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] Sent: Thursday, March 06, 2008 4:47 PM To: ext David B Harrington; netconf@ietf.org Subject: RE: [Netconf] Agenda for NETCONF WG session at IETF #71 Sorry about that, AC is meant to be "Access Control". Cheers, Mehmet -------------------------------------------------------------------------- From: ext David B Harrington [mailto:dbharrington@comcast.net] Sent: Thursday, March 06, 2008 10:11 PM To: Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] Agenda for NETCONF WG session at IETF #71 Hi, You use abbreviations in the agenda without spelling them out anywhere. What is AOB? I figured it out, but AC isn't spelled out anywhere. dbh ------------------------------------------------------------------------ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 06, 2008 3:02 PM To: netconf@ietf.org Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 Hi All, I uploaded the agenda and WG status slides: https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf Presenters, please send me your slides prior to the meeting. Thank you. BTW: We still need minute takers ;-) CU in Philly. Cheers, Mehmet ---------------------------------------------------------------------- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, February 28, 2008 10:41 AM To: netconf@ops.ietf.org Cc: ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) Subject: Agenda for NETCONF WG session at IETF #71 Dear NETCONF WG, below is an update for the agenda of the NETCONF WG session at the IETF #71. Our main focus in the session will be on open issue discussion. Please let us know before hand about your implementation. Please let us also know whether you have a concrete topic for the open mic session. We still need volunteers as scribe and minute taker. As you know the session will not start before we have them ;-). Bert & Mehmet _____________________________________________ NETCONF WG IETF 71, Philadelphia, PA, USA MONDAY, March 10, 2008 1740-1950 Scribes (needs to be organized before the session), Agenda bashing (2 minutes) Use of mailing lists, WG status review (10 minutes) Current charter items: 1. NETCONF over TLS (20 minutes) draft-ietf-netconf-tls-01.txt 2. Fine-grained locking (20 minutes) draft-ietf-netconf-partial-lock-00.txt 3. Netconf monitoring (20 minutes) draft-ietf-netconf-monitoring-00.txt Discussion on ongoing implementations (10 minutes) Who is implementing what? Should we plan an interop-event for testing of RFC 4141-4144 to get them to DS? AOB Open mike One hot topic is e.g. the NETCONF-related requirements on DML. Any other hot topics to discuss? Note (this is not part of the agenda): We are not going to discuss solutions in open mic slot. This is just because we have some time and want to give you the opportunity to sort out the NETCONF-related requirements as a preparation for the Canmod BoF. ------=_NextPart_000_0393_01C88099.198C35F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Agenda for NETCONF WG session at IETF #71
Any=20 Other Businesss (of course). I thought this is a pretty well=20 known
acronym for meeting agendas, no?
 

Bert Wijnen

-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens = David=20 B Harrington
Verzonden: vrijdag 7 maart 2008 = 20:47
Aan:=20 'Ersue, Mehmet (NSN - DE/Muenich)'; = netconf@ietf.org
Onderwerp: Re:=20 [Netconf] Agenda for NETCONF WG session at IETF = #71

and what is AOB?

From: Ersue, Mehmet (NSN - = DE/Muenich)=20 [mailto:mehmet.ersue@nsn.com]
Sent: Thursday, March 06, = 2008 4:47=20 PM
To: ext David B Harrington; = netconf@ietf.org
Subject:=20 RE: [Netconf] Agenda for NETCONF WG session at IETF = #71

Sorry about that, AC is meant to be "Access = Control".
 
Cheers,
Mehmet
 

From: ext David B Harrington=20 [mailto:dbharrington@comcast.net]
Sent: Thursday, March = 06,=20 2008 10:11 PM
To: Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Subject: RE: [Netconf] Agenda for = NETCONF WG=20 session at IETF #71

Hi,
 
You use abbreviations in the agenda = without spelling=20 them out anywhere.
What is AOB?
I figured it out, but AC isn't spelled = out=20 anywhere.
 
dbh

From: = netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = Mehmet (NSN=20 - DE/Muenich)
Sent: Thursday, March 06, 2008 3:02=20 PM
To: netconf@ietf.org
Subject: Re: = [Netconf]=20 Agenda for NETCONF WG session at IETF #71

Hi All,
 
I uploaded the agenda and WG status=20 slides:
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Presenters, please send me your=20 slides prior to the =
meeting. Thank=20 you.
 
BTW: We still need minute takers=20 ;-)
 
CU in Philly.

Cheers,
Mehmet

 

From: = owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext = Ersue,=20 Mehmet (NSN - DE/Muenich)
Sent: Thursday, February = 28, 2008=20 10:41 AM
To: netconf@ops.ietf.org
Cc: ext = Bert=20 Wijnen - IETF; ext Romascanu, Dan (Dan)
Subject: = Agenda for=20 NETCONF WG session at IETF #71


Dear NETCONF=20 WG,

below is an = update for the=20 agenda of the NETCONF WG session
at the IETF #71.

Our main = focus in the=20 session will be on open issue discussion. =
Please let us know = before hand about=20 your implementation.
Please let us also know whether you = have a=20 concrete topic for
the open mic session.

We still need = volunteers as=20 scribe and minute taker. As you
know the session will not start before = we have=20 them ;-).

Bert &=20 Mehmet

_____________________________________________=20

NETCONF = WG=20
IETF 71, = Philadelphia, PA,=20 USA

MONDAY, March = 10, 2008=20 1740-1950

  = Scribes (needs to be=20 organized before the session),
  Agenda bashing (2 = minutes)=20

  Use of = mailing=20 lists,
  WG status review (10 minutes) =

  = Current charter=20 items:

    1.=20 NETCONF over TLS (20 minutes)

      =20 draft-ietf-netconf-tls-01.txt

    2.=20 Fine-grained locking (20 minutes)

      =20 draft-ietf-netconf-partial-lock-00.txt

    3.=20 Netconf monitoring (20 minutes)

      =20 draft-ietf-netconf-monitoring-00.txt

  = Discussion on=20 ongoing implementations (10 minutes)

      Who is implementing=20 what?
      Should we plan an = interop-event=20 for testing of
      RFC 4141-4144 to get = them to DS?=20

  = AOB=20

  Open = mike=20

      One hot topic is e.g. = the=20 NETCONF-related requirements on DML.
      Any=20 other hot topics to discuss?

Note (this is = not part of=20 the agenda):
We are not going to discuss solutions in open mic = slot.=20
This is just=20 because we have some time and want to give =
you the opportunity to = sort out the=20 NETCONF-related
requirements as a preparation for the Canmod=20 BoF.=20 =


------=_NextPart_000_0393_01C88099.198C35F0-- --===============0196709585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0196709585==-- From netconf-bounces@ietf.org Sat Mar 8 06:22:40 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9229328D6A9; Sat, 8 Mar 2008 06:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.896 X-Spam-Level: X-Spam-Status: No, score=-99.896 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq2NL3LbwxbY; Sat, 8 Mar 2008 06:22:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439C028CA9B; Sat, 8 Mar 2008 06:01:48 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4811728E1AA for ; Sat, 8 Mar 2008 06:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQwF6vjPkV+0 for ; Sat, 8 Mar 2008 06:01:44 -0800 (PST) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id D76BC28CFB0 for ; Fri, 7 Mar 2008 12:20:47 -0800 (PST) Received: (qmail 50576 invoked from network); 7 Mar 2008 20:20:35 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 7 Mar 2008 20:20:35 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , Date: Fri, 7 Mar 2008 21:20:42 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <009001c8808c$1013f7e0$0600a8c0@china.huawei.com> Importance: Normal Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0196709585==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0196709585== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0393_01C88099.198C35F0" This is a multi-part message in MIME format. ------=_NextPart_000_0393_01C88099.198C35F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Agenda for NETCONF WG session at IETF #71Any Other Businesss (of course). I thought this is a pretty well known acronym for meeting agendas, no? Bert Wijnen -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David B Harrington Verzonden: vrijdag 7 maart 2008 20:47 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 and what is AOB? ---------------------------------------------------------------------------- From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] Sent: Thursday, March 06, 2008 4:47 PM To: ext David B Harrington; netconf@ietf.org Subject: RE: [Netconf] Agenda for NETCONF WG session at IETF #71 Sorry about that, AC is meant to be "Access Control". Cheers, Mehmet -------------------------------------------------------------------------- From: ext David B Harrington [mailto:dbharrington@comcast.net] Sent: Thursday, March 06, 2008 10:11 PM To: Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] Agenda for NETCONF WG session at IETF #71 Hi, You use abbreviations in the agenda without spelling them out anywhere. What is AOB? I figured it out, but AC isn't spelled out anywhere. dbh ------------------------------------------------------------------------ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 06, 2008 3:02 PM To: netconf@ietf.org Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 Hi All, I uploaded the agenda and WG status slides: https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf Presenters, please send me your slides prior to the meeting. Thank you. BTW: We still need minute takers ;-) CU in Philly. Cheers, Mehmet ---------------------------------------------------------------------- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, February 28, 2008 10:41 AM To: netconf@ops.ietf.org Cc: ext Bert Wijnen - IETF; ext Romascanu, Dan (Dan) Subject: Agenda for NETCONF WG session at IETF #71 Dear NETCONF WG, below is an update for the agenda of the NETCONF WG session at the IETF #71. Our main focus in the session will be on open issue discussion. Please let us know before hand about your implementation. Please let us also know whether you have a concrete topic for the open mic session. We still need volunteers as scribe and minute taker. As you know the session will not start before we have them ;-). Bert & Mehmet _____________________________________________ NETCONF WG IETF 71, Philadelphia, PA, USA MONDAY, March 10, 2008 1740-1950 Scribes (needs to be organized before the session), Agenda bashing (2 minutes) Use of mailing lists, WG status review (10 minutes) Current charter items: 1. NETCONF over TLS (20 minutes) draft-ietf-netconf-tls-01.txt 2. Fine-grained locking (20 minutes) draft-ietf-netconf-partial-lock-00.txt 3. Netconf monitoring (20 minutes) draft-ietf-netconf-monitoring-00.txt Discussion on ongoing implementations (10 minutes) Who is implementing what? Should we plan an interop-event for testing of RFC 4141-4144 to get them to DS? AOB Open mike One hot topic is e.g. the NETCONF-related requirements on DML. Any other hot topics to discuss? Note (this is not part of the agenda): We are not going to discuss solutions in open mic slot. This is just because we have some time and want to give you the opportunity to sort out the NETCONF-related requirements as a preparation for the Canmod BoF. ------=_NextPart_000_0393_01C88099.198C35F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Agenda for NETCONF WG session at IETF #71
Any=20 Other Businesss (of course). I thought this is a pretty well=20 known
acronym for meeting agendas, no?
 

Bert Wijnen

-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens = David=20 B Harrington
Verzonden: vrijdag 7 maart 2008 = 20:47
Aan:=20 'Ersue, Mehmet (NSN - DE/Muenich)'; = netconf@ietf.org
Onderwerp: Re:=20 [Netconf] Agenda for NETCONF WG session at IETF = #71

and what is AOB?

From: Ersue, Mehmet (NSN - = DE/Muenich)=20 [mailto:mehmet.ersue@nsn.com]
Sent: Thursday, March 06, = 2008 4:47=20 PM
To: ext David B Harrington; = netconf@ietf.org
Subject:=20 RE: [Netconf] Agenda for NETCONF WG session at IETF = #71

Sorry about that, AC is meant to be "Access = Control".
 
Cheers,
Mehmet
 

From: ext David B Harrington=20 [mailto:dbharrington@comcast.net]
Sent: Thursday, March = 06,=20 2008 10:11 PM
To: Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Subject: RE: [Netconf] Agenda for = NETCONF WG=20 session at IETF #71

Hi,
 
You use abbreviations in the agenda = without spelling=20 them out anywhere.
What is AOB?
I figured it out, but AC isn't spelled = out=20 anywhere.
 
dbh

From: = netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = Mehmet (NSN=20 - DE/Muenich)
Sent: Thursday, March 06, 2008 3:02=20 PM
To: netconf@ietf.org
Subject: Re: = [Netconf]=20 Agenda for NETCONF WG session at IETF #71

Hi All,
 
I uploaded the agenda and WG status=20 slides:
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Presenters, please send me your=20 slides prior to the =
meeting. Thank=20 you.
 
BTW: We still need minute takers=20 ;-)
 
CU in Philly.

Cheers,
Mehmet

 

From: = owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext = Ersue,=20 Mehmet (NSN - DE/Muenich)
Sent: Thursday, February = 28, 2008=20 10:41 AM
To: netconf@ops.ietf.org
Cc: ext = Bert=20 Wijnen - IETF; ext Romascanu, Dan (Dan)
Subject: = Agenda for=20 NETCONF WG session at IETF #71


Dear NETCONF=20 WG,

below is an = update for the=20 agenda of the NETCONF WG session
at the IETF #71.

Our main = focus in the=20 session will be on open issue discussion. =
Please let us know = before hand about=20 your implementation.
Please let us also know whether you = have a=20 concrete topic for
the open mic session.

We still need = volunteers as=20 scribe and minute taker. As you
know the session will not start before = we have=20 them ;-).

Bert &=20 Mehmet

_____________________________________________=20

NETCONF = WG=20
IETF 71, = Philadelphia, PA,=20 USA

MONDAY, March = 10, 2008=20 1740-1950

  = Scribes (needs to be=20 organized before the session),
  Agenda bashing (2 = minutes)=20

  Use of = mailing=20 lists,
  WG status review (10 minutes) =

  = Current charter=20 items:

    1.=20 NETCONF over TLS (20 minutes)

      =20 draft-ietf-netconf-tls-01.txt

    2.=20 Fine-grained locking (20 minutes)

      =20 draft-ietf-netconf-partial-lock-00.txt

    3.=20 Netconf monitoring (20 minutes)

      =20 draft-ietf-netconf-monitoring-00.txt

  = Discussion on=20 ongoing implementations (10 minutes)

      Who is implementing=20 what?
      Should we plan an = interop-event=20 for testing of
      RFC 4141-4144 to get = them to DS?=20

  = AOB=20

  Open = mike=20

      One hot topic is e.g. = the=20 NETCONF-related requirements on DML.
      Any=20 other hot topics to discuss?

Note (this is = not part of=20 the agenda):
We are not going to discuss solutions in open mic = slot.=20
This is just=20 because we have some time and want to give =
you the opportunity to = sort out the=20 NETCONF-related
requirements as a preparation for the Canmod=20 BoF.=20 =


------=_NextPart_000_0393_01C88099.198C35F0-- --===============0196709585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0196709585==-- From netconf-bounces@ietf.org Sat Mar 8 06:23:59 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F198F3A7527; Sat, 8 Mar 2008 06:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.371 X-Spam-Level: X-Spam-Status: No, score=-100.371 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMzbM3Rs4fx3; Sat, 8 Mar 2008 06:23:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF8828DF32; Sat, 8 Mar 2008 06:07:59 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F9828DBFF for ; Sat, 8 Mar 2008 06:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slrXo6csY2Op for ; Sat, 8 Mar 2008 06:07:53 -0800 (PST) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 81915292FBA for ; Fri, 7 Mar 2008 14:24:55 -0800 (PST) Received: (qmail 37270 invoked from network); 7 Mar 2008 22:24:44 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 7 Mar 2008 22:24:44 -0000 From: "Bert Wijnen - IETF" To: Date: Fri, 7 Mar 2008 23:24:51 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] FW: NOTE WELL Statement for WG Sessions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WG members, as you can see below, we are requested to show the NOTE WELL statement at the beginning of our session. We will do so, but we won't dwell on it. So by posting this, I hope you will all be familiar with this NOTE WELL when you come into the meeting. Bert Wijnen -----Oorspronkelijk bericht----- Van: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org]Namens Alexa Morris Verzonden: dinsdag 4 maart 2008 5:20 Aan: 'Working Group Chairs' CC: Ray Pelletier; Russ Housley Onderwerp: NOTE WELL Statement for WG Sessions WG Chairs, I want to inform you that we've added a reference to the NOTE WELL statement on the Blue Sheets that will be placed in all WG session meeting rooms. In addition, we'd like to ask all of you to please display the NOTE WELL statement at the start of each of your sessions. We've uploaded both a PPT and a PDF version of the NOTE WELL statement to the WG Chairs webpage: http://www.ietf.org/IESG/wgchairs.html/. The links can be found under IPR Information or can be accessed directly here: PPT: http://www.ietf.org/NoteWell-IETF71.ppt PDF: http://www.ietf.org/NoteWell-IETF71.pdf Please don't hesitate to contact me if you have any questions. Regards, Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Mar 8 06:23:59 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F198F3A7527; Sat, 8 Mar 2008 06:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.371 X-Spam-Level: X-Spam-Status: No, score=-100.371 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMzbM3Rs4fx3; Sat, 8 Mar 2008 06:23:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF8828DF32; Sat, 8 Mar 2008 06:07:59 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F9828DBFF for ; Sat, 8 Mar 2008 06:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slrXo6csY2Op for ; Sat, 8 Mar 2008 06:07:53 -0800 (PST) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 81915292FBA for ; Fri, 7 Mar 2008 14:24:55 -0800 (PST) Received: (qmail 37270 invoked from network); 7 Mar 2008 22:24:44 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 7 Mar 2008 22:24:44 -0000 From: "Bert Wijnen - IETF" To: Date: Fri, 7 Mar 2008 23:24:51 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] FW: NOTE WELL Statement for WG Sessions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WG members, as you can see below, we are requested to show the NOTE WELL statement at the beginning of our session. We will do so, but we won't dwell on it. So by posting this, I hope you will all be familiar with this NOTE WELL when you come into the meeting. Bert Wijnen -----Oorspronkelijk bericht----- Van: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org]Namens Alexa Morris Verzonden: dinsdag 4 maart 2008 5:20 Aan: 'Working Group Chairs' CC: Ray Pelletier; Russ Housley Onderwerp: NOTE WELL Statement for WG Sessions WG Chairs, I want to inform you that we've added a reference to the NOTE WELL statement on the Blue Sheets that will be placed in all WG session meeting rooms. In addition, we'd like to ask all of you to please display the NOTE WELL statement at the start of each of your sessions. We've uploaded both a PPT and a PDF version of the NOTE WELL statement to the WG Chairs webpage: http://www.ietf.org/IESG/wgchairs.html/. The links can be found under IPR Information or can be accessed directly here: PPT: http://www.ietf.org/NoteWell-IETF71.ppt PDF: http://www.ietf.org/NoteWell-IETF71.pdf Please don't hesitate to contact me if you have any questions. Regards, Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Mar 10 07:55:21 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9BAE3A6F28; Mon, 10 Mar 2008 07:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHCq8yRIMgtp; Mon, 10 Mar 2008 07:55:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC5A28D62F; Mon, 10 Mar 2008 07:28:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164A828D1D1 for ; Mon, 10 Mar 2008 07:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reFAzWCdE07V for ; Mon, 10 Mar 2008 07:28:14 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 9394B293652 for ; Mon, 10 Mar 2008 05:32:26 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m2ACTwFT013148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 13:29:58 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m2ACTpZk028724; Mon, 10 Mar 2008 13:29:55 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Mar 2008 13:29:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 13:29:54 +0100 Message-ID: In-Reply-To: <47D0A134.2020208@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach/9rcpPsGgP3+ZSxWoEZD2wxnUBgCs0IMA References: <47D0A134.2020208@andybierman.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Andy Bierman" X-OriginalArrivalTime: 10 Mar 2008 12:29:55.0368 (UTC) FILETIME=[724BCA80:01C882AA] Cc: netconf@ietf.org Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Andy, I appreciate your input. Let's talk on this in the open mic slot. Cheers, Mehmet > -----Original Message----- > From: ext Andy Bierman [mailto:ietf@andybierman.com] > Sent: Friday, March 07, 2008 2:58 AM > To: Ersue, Mehmet (NSN - DE/Muenich) > Cc: netconf@ops.ietf.org; ext Bert Wijnen - IETF; ext > Romascanu, Dan (Dan) > Subject: Re: Agenda for NETCONF WG sFrom netconf-bounces@ietf.org Mon Mar 10 07:55:21 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9BAE3A6F28; Mon, 10 Mar 2008 07:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHCq8yRIMgtp; Mon, 10 Mar 2008 07:55:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC5A28D62F; Mon, 10 Mar 2008 07:28:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164A828D1D1 for ; Mon, 10 Mar 2008 07:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reFAzWCdE07V for ; Mon, 10 Mar 2008 07:28:14 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 9394B293652 for ; Mon, 10 Mar 2008 05:32:26 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m2ACTwFT013148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 13:29:58 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m2ACTpZk028724; Mon, 10 Mar 2008 13:29:55 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Mar 2008 13:29:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 13:29:54 +0100 Message-ID: In-Reply-To: <47D0A134.2020208@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for NETCONF WG session at IETF #71 Thread-Index: Ach/9rcpPsGgP3+ZSxWoEZD2wxnUBgCs0IMA References: <47D0A134.2020208@andybierman.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Andy Bierman" X-OriginalArrivalTime: 10 Mar 2008 12:29:55.0368 (UTC) FILETIME=[724BCA80:01C882AA] Cc: netconf@ietf.org Subject: Re: [Netconf] Agenda for NETCONF WG session at IETF #71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Andy, I appreciate your input. Let's talk on this in the open mic slot. Cheers, Mehmet > -----Original Message----- > From: ext Andy Bierman [mailto:ietf@andybierman.com] > Sent: Friday, March 07, 2008 2:58 AM > To: Ersue, Mehmet (NSN - DE/Muenich) > Cc: netconf@ops.ietf.org; ext Bert Wijnen - IETF; ext > Romascanu, Dan (Dan) > Subject: Re: Agenda for NETCONF WG session at IETF #71 > > Ersue, Mehmet (NSN - DE/Muenich) wrote: > > > > Dear NETCONF WG, > > > > below is an update for the agenda of the NETCONF WG session > > at the IETF #71. > > > > Our main focus in the session will be on open issue discussion. > > Please let us know before hand about your implementation. > > Please let us also know whether you have a concrete topic for > > the open mic session. > > > > I have some running NETCONF code and a topic for the meeting, > not that the 2 are related in any way... > > The WG agreed that the NETCONF Notifications work > was not finished, and some standard notification content > would really make the notification delivery features > more relevant to our standardization efforts. > > Yet nothing has been done. > What about a config-change event? > When will any standard events for the NETCONF stream be defined? > > > > > We still need volunteers as scribe and minute taker. As you > > know the session will not start before we have them ;-). > > > > Bert & Mehmet > > > > > Andy > > > > _____________________________________________ > > > > NETCONF WG > > IETF 71, Philadelphia, PA, USA > > > > MONDAY, March 10, 2008 1740-1950 > > > > Scribes (needs to be organized before the session), > > Agenda bashing (2 minutes) > > > > Use of mailing lists, > > WG status review (10 minutes) > > > > Current charter items: > > > > 1. NETCONF over TLS (20 minutes) > > > > draft-ietf-netconf-tls-01.txt > > > > 2. Fine-grained locking (20 minutes) > > > > draft-ietf-netconf-partial-lock-00.txt > > > > 3. Netconf monitoring (20 minutes) > > > > draft-ietf-netconf-monitoring-00.txt > > > > Discussion on ongoing implementations (10 minutes) > > > > Who is implementing what? > > Should we plan an interop-event for testing of > > RFC 4141-4144 to get them to DS? > > > > AOB > > > > Open mike > > > > One hot topic is e.g. the NETCONF-related requirements on DML. > > Any other hot topics to discuss? > > > > Note (this is not part of the agenda): > > We are not going to discuss solutions in open mic slot. > > This is just because we have some time and want to give > > you the opportunity to sort out the NETCONF-related > > requirements as a preparation for the Canmod BoF. > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ession at IETF #71 > > Ersue, Mehmet (NSN - DE/Muenich) wrote: > > > > Dear NETCONF WG, > > > > below is an update for the agenda of the NETCONF WG session > > at the IETF #71. > > > > Our main focus in the session will be on open issue discussion. > > Please let us know before hand about your implementation. > > Please let us also know whether you have a concrete topic for > > the open mic session. > > > > I have some running NETCONF code and a topic for the meeting, > not that the 2 are related in any way... > > The WG agreed that the NETCONF Notifications work > was not finished, and some standard notification content > would really make the notification delivery features > more relevant to our standardization efforts. > > Yet nothing has been done. > What about a config-change event? > When will any standard events for the NETCONF stream be defined? > > > > > We still need volunteers as scribe and minute taker. As you > > know the session will not start before we have them ;-). > > > > Bert & Mehmet > > > > > Andy > > > > _____________________________________________ > > > > NETCONF WG > > IETF 71, Philadelphia, PA, USA > > > > MONDAY, March 10, 2008 1740-1950 > > > > Scribes (needs to be organized before the session), > > Agenda bashing (2 minutes) > > > > Use of mailing lists, > > WG status review (10 minutes) > > > > Current charter items: > > > > 1. NETCONF over TLS (20 minutes) > > > > draft-ietf-netconf-tls-01.txt > > > > 2. Fine-grained locking (20 minutes) > > > > draft-ietf-netconf-partial-lock-00.txt > > > > 3. Netconf monitoring (20 minutes) > > > > draft-ietf-netconf-monitoring-00.txt > > > > Discussion on ongoing implementations (10 minutes) > > > > Who is implementing what? > > Should we plan an interop-event for testing of > > RFC 4141-4144 to get them to DS? > > > > AOB > > > > Open mike > > > > One hot topic is e.g. the NETCONF-related requirements on DML. > > Any other hot topics to discuss? > > > > Note (this is not part of the agenda): > > We are not going to discuss solutions in open mic slot. > > This is just because we have some time and want to give > > you the opportunity to sort out the NETCONF-related > > requirements as a preparation for the Canmod BoF. > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From owner-netconf@ops.ietf.org Mon Mar 10 09:17:04 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8923A6879 for ; Mon, 10 Mar 2008 09:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.035 X-Spam-Level: X-Spam-Status: No, score=0.035 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+lw0JeWqEHi for ; Mon, 10 Mar 2008 09:17:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 131D728C27D for ; Mon, 10 Mar 2008 08:47:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JYk41-000KWY-0y for netconf-data@psg.com; Mon, 10 Mar 2008 15:37:21 +0000 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JYk3q-000KUX-Gt for netconf@ops.ietf.org; Mon, 10 Mar 2008 15:37:15 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E3988A570 for ; Mon, 10 Mar 2008 16:37:09 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31769-02-8; Mon, 10 Mar 2008 16:37:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9E528A56E; Mon, 10 Mar 2008 16:33:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 829EA4F70F0; Mon, 10 Mar 2008 16:33:09 +0100 (CET) Date: Mon, 10 Mar 2008 16:33:09 +0100 From: Juergen Schoenwaelder To: netconf@ops.ietf.org Subject: review of draft-ietf-netconf-tls-01 Message-ID: <20080310153309.GB17320@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk My comments on draft-ietf-netconf-tls-01: - General: Reasonable document, but I am not sure the password authentication fits the RADIUS requirements - I read: When the NETCONF peer processes a closure request of the NETCONF connection, it MUST send a TLS close_notify alert before closing the connection. The phrase "processes a closure request of the NETCONF connection" sounds fuzzy to me. Perhaps you mean this: When the NETCONF peer closes the NETCONF connection, it MUST send a TLS close_notify alert before closing the TCP connection. I note that there might be cases where this is not possible, e.g. the peer is dying before if gets to say good bye. - I read: Unless some other fatal alert has been transmitted, ... Who is transmitting a fatal alert to whom and how? Perhaps you mean: Unless a fatal error has occured, ... - What is the 'write side' of a connection? - Second sentence in section 3. seems to be garbled. - Can the password based authentication scheme be hooked into RADIUS? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 10 09:17:37 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7886D3A68C6 for ; Mon, 10 Mar 2008 09:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGNxsfdacRQm for ; Mon, 10 Mar 2008 09:17:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F0A028C5AA for ; Mon, 10 Mar 2008 08:49:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JYk6o-000LCs-VV for netconf-data@psg.com; Mon, 10 Mar 2008 15:40:14 +0000 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JYk6d-000L55-4a for netconf@ops.ietf.org; Mon, 10 Mar 2008 15:40:08 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EB198AB80 for ; Mon, 10 Mar 2008 16:40:02 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31481-06-8; Mon, 10 Mar 2008 16:39:57 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 712F48A71F; Mon, 10 Mar 2008 16:36:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4A17A4F7152; Mon, 10 Mar 2008 16:36:18 +0100 (CET) Date: Mon, 10 Mar 2008 16:36:18 +0100 From: Juergen Schoenwaelder To: netconf@ops.ietf.org Subject: review of draft-ietf-netconf-monitoring-01 Message-ID: <20080310153618.GD17320@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk My comments on draft-ietf-netconf-monitoring-01: - General: This document needs a lot of work. - The first two sentences of the abstract should be moved into the introduction and the introduction clearly could have a bit more text. - Remove the term Managed Object - it does not seem to be used. - Is 'netconfState' a good idea? How do we in general like to organize data models? - In the following text, is the right verb exchanged or announced? Minimally must contain the same capabilities exchanged during session setup. If a device reports more than announced during the session setup, how can I actually find out what has been announced for a given session? Is the idea that an implementation can have capabilities that are only announced on some session?? - Several of the elements (e.g. transport, protocol) are just strings - so how do we achieve interoperability? - The description of sourceIdentifier is inconsistent with the XSD. - Can you you refer to inet:ip-address in the XSD?? - Where are things such as netconf:SessionId or netconf:configNameType or netconf:filterInlineType defined? Is there a common capitalization rule for identifiers or is this just random? - I read: sessionId: unique identifier for the notifications. Same value as returned in 'sessions' to allow correlation. I assume sessionId is an identifier for the notification session, not for the notifications... - What is NetconfSubscriptionInfo?? And how does it map to "event subscriptions"? - I don't find any of the schema reporting stuff in the XSD. - I read: location: a location from which the schema can be retrieved. Can be either on the network device (eg: URL), retrievable explicitly via netconf ('netconf') or some network location (eg: URL). What is the difference between a 'network device' and a 'network location'?? - Section 3 is all about "will be" but not about how things are actually done. - I read: and elements are mandatory and their values are unique It is unclear what specifically is going to be unique. All the identifers? All version numbers? The combinations of identifiers with version numbers? Something else? - Is there concensus that we do access control in units of schemas? - How do I actually retrieve a schema via NETCONF? I know what to do with a URL but this is where it ends... - The list-schema example is not even valid XML. I am missing a clear definition of the proposed NETCONF capability. And whay is list-schema good for - it seems to do the same as the get operation, no? - I suggest to remove the first paragraph of section 4 since this text is also in the security considerations (where it belongs). - There needs to be IANA considerations since you need to allocate at least a URN. - I would love to have an appendix with a YANG module. - I did not bother to read the XSD. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 10 09:20:28 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE4E28CA51 for ; Mon, 10 Mar 2008 09:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.24 X-Spam-Level: X-Spam-Status: No, score=0.24 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKr5-OchUqAN for ; Mon, 10 Mar 2008 09:20:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62C8B28CC1C for ; Mon, 10 Mar 2008 08:57:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JYk5f-000Kqs-JH for netconf-data@psg.com; Mon, 10 Mar 2008 15:39:03 +0000 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JYk5Y-000KpS-Hf for netconf@ops.ietf.org; Mon, 10 Mar 2008 15:38:58 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B463D8AA0C for ; Mon, 10 Mar 2008 16:38:55 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31769-02-28; Mon, 10 Mar 2008 16:38:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 141658A8EF; Mon, 10 Mar 2008 16:35:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DDF924F7125; Mon, 10 Mar 2008 16:35:12 +0100 (CET) Date: Mon, 10 Mar 2008 16:35:12 +0100 From: Juergen Schoenwaelder To: netconf@ops.ietf.org Subject: review of draft-ietf-netconf-partial-lock-01 Message-ID: <20080310153512.GC17320@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk - General: This document is already in a reasonably good shape. - Where does NETCONF define what an instance identifier is? Is this the right place for such a definition in case there is no official definition yet? - Is 'string' the right data type for the leaf-list 'select'? Should we extend the common YANG type definition modules to have more suitable types readily available? - Add more descriptions to the YANG module; should there also be more defined types, e.g. a type for the lockId instead of using uint32 everywhere? - The notion seems to be inconsistent in the usage of camel notation; would help consistency to pick a convention and then stick to it. - I did not bother to read the XSD. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 10 14:42:18 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7CA28C131 for ; Mon, 10 Mar 2008 14:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.104 X-Spam-Level: ** X-Spam-Status: No, score=2.104 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_ILLEGAL_IP=1.908, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-FykOJqyiNk for ; Mon, 10 Mar 2008 14:42:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1EB528C1E9 for ; Mon, 10 Mar 2008 14:41:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JYpb4-000Lxm-A6 for netconf-data@psg.com; Mon, 10 Mar 2008 21:31:50 +0000 Received: from [133.145.228.44] (helo=mail9.hitachi.co.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JYpb0-000Lwy-Qy for netconf@ops.ietf.org; Mon, 10 Mar 2008 21:31:48 +0000 Received: from mlsv13.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id 5157D37C82 for ; Tue, 11 Mar 2008 06:31:46 +0900 (JST) Received: from mfilter-s2.hitachi.co.jp by mlsv13.hitachi.co.jp (8.13.1/8.13.1) id m2ALVkjE007306; Tue, 11 Mar 2008 06:31:46 +0900 Received: from vshuts1.hitachi.co.jp (unverified) by mfilter-s2.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Tue, 11 Mar 2008 06:31:46 +0900 Received: from vshuts1.hitachi.co.jp (unknown [127.0.0.1]) by vshuts1.hitachi.co.jp (Symantec Mail Security) with ESMTP id 12B47272F4E for ; Tue, 11 Mar 2008 06:31:46 +0900 (JST) X-AuditID: 0ac90646-abab4ba000002821-b9-47d5a8c292f4 Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts1.hitachi.co.jp (Symantec Mail Security) with ESMTP id F3B19272F46 for ; Tue, 11 Mar 2008 06:31:45 +0900 (JST) Received: from [0.0.0.0] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id m2ALViK12247278; Tue, 11 Mar 2008 06:31:45 +0900 Message-ID: <47D5A8BE.3020002@hitachi.com> Date: Tue, 11 Mar 2008 06:31:42 +0900 From: OKITA Hideki User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: review of draft-ietf-netconf-monitoring-01 References: <20080310153618.GD17320@elstar.local> In-Reply-To: <20080310153618.GD17320@elstar.local> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, A comment for schema list retrieval method. Juergen Schoenwaelder wrote: > and elements are > mandatory and their values are unique > > It is unclear what specifically is going to be unique. All the > identifers? All version numbers? The combinations of identifiers > with version numbers? Something else? > How about to encode the and in a namespace property in an element for a schema like following? Ambiguity can be avoided. > location: > a location from which the schema can be retrieved. Can be either on > the network device (eg: URL), retrievable explicitly via netconf > ('netconf') or some network location (eg: URL). > > What is the difference between a 'network device' and a 'network > location'?? > It seems to say that the schema can be retrieved from a NETCONF device via a method described in the URL (e.g. FTP). from a NETCONF device on its NETCONF session. from some network location via a method described in the URL (e.g. FTP). Hideki Okita -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From netconf-bounces@ietf.org Mon Mar 17 02:16:33 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B86C3A6CD3; Mon, 17 Mar 2008 02:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.327 X-Spam-Level: X-Spam-Status: No, score=-100.327 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9W9S7gFdG3U; Mon, 17 Mar 2008 02:16:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B29B3A6947; Mon, 17 Mar 2008 02:16:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693E33A67F9 for ; Mon, 17 Mar 2008 02:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ1SC-9YX1Nt for ; Mon, 17 Mar 2008 02:16:30 -0700 (PDT) Received: from web27804.mail.ukl.yahoo.com (web27804.mail.ukl.yahoo.com [217.146.182.9]) by core3.amsl.com (Postfix) with SMTP id CAAF53A6B37 for ; Mon, 17 Mar 2008 02:16:29 -0700 (PDT) Received: (qmail 59156 invoked by uid 60001); 17 Mar 2008 09:14:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ipgCPNYkjVz9mTQoCImhZQ1G+6locla2FkuTq6QwhEDMVmZrnegpK9OT5MBJsAjlMHT+I5fMQyolP5cQOhY8NtNfzYXGdfQdnI6PQRpc23+NVQ6KLF2g3ijwbzk1tSc7v+YwV3goXGrg3uehcqWHp47eeQdLloMckon92X/eTsU=; X-YMail-OSG: cO7giecVM1nHY4ib.GKYFqjseDVLtCHgO7FsUFyWNeu7bTsFd1UsDflRr.nhfAdk4G.8teA3zdbtdi4EIW8zvRdXd58MJDaWPQ17HbD2J0uLH7AHqtNDl.4kfBQ- Received: from [217.115.75.229] by web27804.mail.ukl.yahoo.com via HTTP; Mon, 17 Mar 2008 09:14:12 GMT X-Mailer: YahooMailRC/902.38 YahooMailWebService/0.7.162 Date: Mon, 17 Mar 2008 09:14:12 +0000 (GMT) From: Mehmet Ersue To: NETCONF MIME-Version: 1.0 Message-ID: <603801.59100.qm@web27804.mail.ukl.yahoo.com> Subject: [Netconf] WG: NETCONF WG Session Summary X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1570770506==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --===============1570770506== Content-Type: multipart/alternative; boundary="0-932150367-1205745252=:59100" --0-932150367-1205745252=:59100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0AHi All,=0A=0Aplease find below the NETCONF session summary we send =0Ato= Dan during the IETF week.=0A=0ACheers,=0AMehmet=0A=0A=0A----- Weitergeleit= ete Mail ----=0AVon: Mehmet Ersue =0AAn: Dan Romascanu =0ACC: Bert Wijnen =0AGesendet: Mit= twoch, den 12. M=C3=A4rz 2008, 23:13:51 Uhr=0ABetreff: NETCONF WG Session S= ummary=0A=0AHi Dan,=0A=0Aplease find below a short summary of the NETCONF W= G=0Asession on Monday , March 10, 2008, 1740 - 1950:=0A=0A- We had 50 perso= ns in the NETCONF session.=0A- We reviewed the status of the WG=0A- As a re= sult of the LC we had an update for the NETCONF =0A notification draft, wh= ich is now in the hands of IESG.=0A- We went through the chartered WG items= and had a good =0A discussion and review of the documents=0A- We asked th= e work group whether they are going to =0A prepare independent implementat= ions of the charter items=0A The count of the implementation plans for the= different =0A drafts is:=0A - Notification draft: 4 =0A - Partial Lock:= 3 =0A - Monitoring: 3-4 =0A - TLS draft: 0 (The TLS author Muhamad Badra= was not in =0A the session.)=0A- The polling result for the implementa= tions will be confirmed =0A on the maillist. We think the TLS draft may b= e canceled as =0A a charter item if the count remains as '0'.=0A- Nobody = had concerns on the document "Experience of NETCONF =0A over SOAP (Iijima = Tomoyuki)". So it can go ahead as an AD=0A sponsored informational RFC.=0A= - The WG has interest to work on the Access Control Mechanism. =0A Andy Bi= erman and David Harrington volunteered to work on=0A a draft. There was no= volunteer for reviewing. Given the number =0A of things NETCONF related t= hings going on, access control =0A does not seem to be high priority at th= e moment.=0A=0ACheers,=0ABert & Mehmet=0A=0A=0A=0A=0A Lesen Sie Ihre= E-Mails jetzt einfach von unterwegs.. =0A=0A=0A=0A=0A=0A Lesen Sie Ih= re E-Mails jetzt einfach von unterwegs.=0Awww.yahoo.de/go --0-932150367-1205745252=:59100 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi All,

please find below the NETCONF session summary we send <= br>to Dan during the IETF week.

Cheers,
Mehmet


----- Weitergeleitete Mail ----
Von: Mehmet Ersue <m_ersue@yahoo.de&= gt;
An: Dan Romascanu <dromasca@avaya.com>
CC: Bert Wijnen <= bertietf@bwijnen.net>
Gesendet: Mittwoch, den 12. M=C3=A4rz 2008, 23:= 13:51 Uhr
Betreff: NETCONF WG Session Summary

Hi Dan,

ple= ase find below a short summary of the NETCONF WG
session on Monday , Mar= ch 10, 2008, 1740 - 1950:

- We had 50 persons in the NETCONF session.
-= We reviewed the status of the WG
- As a result of the LC we had an upda= te for the NETCONF
  notification draft, which is now in the hands= of IESG.
- We went through the chartered WG items and had a good
&n= bsp; discussion and review of the documents
- We asked the work group wh= ether they are going to
  prepare independent implementations of t= he charter items
  The count of the implementation plans for the di= fferent
  drafts is:
  - Notification draft: 4
  = - Partial Lock: 3
  -=0A Monitoring: 3-4
  - TLS draft: 0= (The TLS author Muhamad Badra was not=0A in
     t= he session.)
- The polling result for the implementations will be confir= med
   on the maillist. We think the TLS draft may be cancele= d as
   a charter item if the count remains as '0'.
- Nobo= dy had concerns on the document "Experience of NETCONF
  over SOAP= (Iijima Tomoyuki)". So it can go ahead as an AD
  sponsored inform= ational RFC.
- The WG has interest to work on the Access Control Mechani= sm.
  Andy Bierman and David Harrington volunteered to work on
=   a draft. There was no volunteer for reviewing. Given the number
=   of things NETCONF related things going on, access control
 = does not seem to be high priority at the moment.

Cheers,
Bert &a= mp; Mehmet

=0A
=0A =0ALesen Sie Ihre E= -Mails jetzt einfach von unterwegs..


=0A =
=0A =0AL= esen Sie Ihre E-Mails auf dem Handy.. --0-932150367-1205745252=:59100-- --===============1570770506== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1570770506==-- From netconf-bounces@ietf.org Mon Mar 17 02:16:33 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B86C3A6CD3; Mon, 17 Mar 2008 02:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.327 X-Spam-Level: X-Spam-Status: No, score=-100.327 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9W9S7gFdG3U; Mon, 17 Mar 2008 02:16:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B29B3A6947; Mon, 17 Mar 2008 02:16:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693E33A67F9 for ; Mon, 17 Mar 2008 02:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ1SC-9YX1Nt for ; Mon, 17 Mar 2008 02:16:30 -0700 (PDT) Received: from web27804.mail.ukl.yahoo.com (web27804.mail.ukl.yahoo.com [217.146.182.9]) by core3.amsl.com (Postfix) with SMTP id CAAF53A6B37 for ; Mon, 17 Mar 2008 02:16:29 -0700 (PDT) Received: (qmail 59156 invoked by uid 60001); 17 Mar 2008 09:14:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ipgCPNYkjVz9mTQoCImhZQ1G+6locla2FkuTq6QwhEDMVmZrnegpK9OT5MBJsAjlMHT+I5fMQyolP5cQOhY8NtNfzYXGdfQdnI6PQRpc23+NVQ6KLF2g3ijwbzk1tSc7v+YwV3goXGrg3uehcqWHp47eeQdLloMckon92X/eTsU=; X-YMail-OSG: cO7giecVM1nHY4ib.GKYFqjseDVLtCHgO7FsUFyWNeu7bTsFd1UsDflRr.nhfAdk4G.8teA3zdbtdi4EIW8zvRdXd58MJDaWPQ17HbD2J0uLH7AHqtNDl.4kfBQ- Received: from [217.115.75.229] by web27804.mail.ukl.yahoo.com via HTTP; Mon, 17 Mar 2008 09:14:12 GMT X-Mailer: YahooMailRC/902.38 YahooMailWebService/0.7.162 Date: Mon, 17 Mar 2008 09:14:12 +0000 (GMT) From: Mehmet Ersue To: NETCONF MIME-Version: 1.0 Message-ID: <603801.59100.qm@web27804.mail.ukl.yahoo.com> Subject: [Netconf] WG: NETCONF WG Session Summary X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1570770506==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --===============1570770506== Content-Type: multipart/alternative; boundary="0-932150367-1205745252=:59100" --0-932150367-1205745252=:59100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0AHi All,=0A=0Aplease find below the NETCONF session summary we send =0Ato= Dan during the IETF week.=0A=0ACheers,=0AMehmet=0A=0A=0A----- Weitergeleit= ete Mail ----=0AVon: Mehmet Ersue =0AAn: Dan Romascanu =0ACC: Bert Wijnen =0AGesendet: Mit= twoch, den 12. M=C3=A4rz 2008, 23:13:51 Uhr=0ABetreff: NETCONF WG Session S= ummary=0A=0AHi Dan,=0A=0Aplease find below a short summary of the NETCONF W= G=0Asession on Monday , March 10, 2008, 1740 - 1950:=0A=0A- We had 50 perso= ns in the NETCONF session.=0A- We reviewed the status of the WG=0A- As a re= sult of the LC we had an update for the NETCONF =0A notification draft, wh= ich is now in the hands of IESG.=0A- We went through the chartered WG items= and had a good =0A discussion and review of the documents=0A- We asked th= e work group whether they are going to =0A prepare independent implementat= ions of the charter items=0A The count of the implementation plans for the= different =0A drafts is:=0A - Notification draft: 4 =0A - Partial Lock:= 3 =0A - Monitoring: 3-4 =0A - TLS draft: 0 (The TLS author Muhamad Badra= was not in =0A the session.)=0A- The polling result for the implementa= tions will be confirmed =0A on the maillist. We think the TLS draft may b= e canceled as =0A a charter item if the count remains as '0'.=0A- Nobody = had concerns on the document "Experience of NETCONF =0A over SOAP (Iijima = Tomoyuki)". So it can go ahead as an AD=0A sponsored informational RFC.=0A= - The WG has interest to work on the Access Control Mechanism. =0A Andy Bi= erman and David Harrington volunteered to work on=0A a draft. There was no= volunteer for reviewing. Given the number =0A of things NETCONF related t= hings going on, access control =0A does not seem to be high priority at th= e moment.=0A=0ACheers,=0ABert & Mehmet=0A=0A=0A=0A=0A Lesen Sie Ihre= E-Mails jetzt einfach von unterwegs.. =0A=0A=0A=0A=0A=0A Lesen Sie Ih= re E-Mails jetzt einfach von unterwegs.=0Awww.yahoo.de/go --0-932150367-1205745252=:59100 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi All,

please find below the NETCONF session summary we send <= br>to Dan during the IETF week.

Cheers,
Mehmet


----- Weitergeleitete Mail ----
Von: Mehmet Ersue <m_ersue@yahoo.de&= gt;
An: Dan Romascanu <dromasca@avaya.com>
CC: Bert Wijnen <= bertietf@bwijnen.net>
Gesendet: Mittwoch, den 12. M=C3=A4rz 2008, 23:= 13:51 Uhr
Betreff: NETCONF WG Session Summary

Hi Dan,

ple= ase find below a short summary of the NETCONF WG
session on Monday , Mar= ch 10, 2008, 1740 - 1950:

- We had 50 persons in the NETCONF session.
-= We reviewed the status of the WG
- As a result of the LC we had an upda= te for the NETCONF
  notification draft, which is now in the hands= of IESG.
- We went through the chartered WG items and had a good
&n= bsp; discussion and review of the documents
- We asked the work group wh= ether they are going to
  prepare independent implementations of t= he charter items
  The count of the implementation plans for the di= fferent
  drafts is:
  - Notification draft: 4
  = - Partial Lock: 3
  -=0A Monitoring: 3-4
  - TLS draft: 0= (The TLS author Muhamad Badra was not=0A in
     t= he session.)
- The polling result for the implementations will be confir= med
   on the maillist. We think the TLS draft may be cancele= d as
   a charter item if the count remains as '0'.
- Nobo= dy had concerns on the document "Experience of NETCONF
  over SOAP= (Iijima Tomoyuki)". So it can go ahead as an AD
  sponsored inform= ational RFC.
- The WG has interest to work on the Access Control Mechani= sm.
  Andy Bierman and David Harrington volunteered to work on
=   a draft. There was no volunteer for reviewing. Given the number
=   of things NETCONF related things going on, access control
 = does not seem to be high priority at the moment.

Cheers,
Bert &a= mp; Mehmet

=0A
=0A =0ALesen Sie Ihre E= -Mails jetzt einfach von unterwegs..


=0A =
=0A =0AL= esen Sie Ihre E-Mails auf dem Handy.. --0-932150367-1205745252=:59100-- --===============1570770506== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1570770506==-- From netconf-bounces@ietf.org Mon Mar 17 05:02:33 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB18528C0FF; Mon, 17 Mar 2008 05:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.406 X-Spam-Level: X-Spam-Status: No, score=-100.406 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbD4DLkMWJu0; Mon, 17 Mar 2008 05:02:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7878528C3B2; Mon, 17 Mar 2008 05:02:28 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D683A6A41 for ; Mon, 17 Mar 2008 05:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfkUtbkcOmO2 for ; Mon, 17 Mar 2008 05:02:25 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id BC9AC28C41A for ; Mon, 17 Mar 2008 05:02:00 -0700 (PDT) Received: (qmail 24305 invoked from network); 17 Mar 2008 11:59:43 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 17 Mar 2008 11:59:43 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Mon, 17 Mar 2008 12:59:55 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] Subject: RE: review of draft-ietf-netconf-monitoring-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Thanks Juergen for your extensive review and detailed comments. I assume the authors/editors will react and/or make changes to the document accordingly. Other WG members: PLEASE do also review and send your comments. Only if we all participate can we come to consensus and create a good quality document. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org]Namens Juergen Schoenwaelder > Verzonden: maandag 10 maart 2008 16:36 > Aan: netconf@ops.ietf.org > Onderwerp: review of draft-ietf-netconf-monitoring-01 > > > > My comments on draft-ietf-netconf-monitoring-01: > > - General: This document needs a lot of work. > > - The first two sentences of the abstract should be moved into the > introduction and the introduction clearly could have a bit more > text. > > - Remove the term Managed Object - it does not seem to be used. > > - Is 'netconfState' a good idea? How do we in general like to organize > data models? > > - In the following text, is the right verb exchanged or announced? > > Minimally must contain the same capabilities exchanged during > session setup. > >From netconf-bounces@ietf.org Mon Mar 17 05:02:33 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB18528C0FF; Mon, 17 Mar 2008 05:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.406 X-Spam-Level: X-Spam-Status: No, score=-100.406 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbD4DLkMWJu0; Mon, 17 Mar 2008 05:02:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7878528C3B2; Mon, 17 Mar 2008 05:02:28 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D683A6A41 for ; Mon, 17 Mar 2008 05:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfkUtbkcOmO2 for ; Mon, 17 Mar 2008 05:02:25 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id BC9AC28C41A for ; Mon, 17 Mar 2008 05:02:00 -0700 (PDT) Received: (qmail 24305 invoked from network); 17 Mar 2008 11:59:43 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 17 Mar 2008 11:59:43 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Mon, 17 Mar 2008 12:59:55 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] Subject: RE: review of draft-ietf-netconf-monitoring-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Thanks Juergen for your extensive review and detailed comments. I assume the authors/editors will react and/or make changes to the document accordingly. Other WG members: PLEASE do also review and send your comments. Only if we all participate can we come to consensus and create a good quality document. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org]Namens Juergen Schoenwaelder > Verzonden: maandag 10 maart 2008 16:36 > Aan: netconf@ops.ietf.org > Onderwerp: review of draft-ietf-netconf-monitoring-01 > > > > My comments on draft-ietf-netconf-monitoring-01: > > - General: This document needs a lot of work. > > - The first two sentences of the abstract should be moved into the > introduction and the introduction clearly could have a bit more > text. > > - Remove the term Managed Object - it does not seem to be used. > > - Is 'netconfState' a good idea? How do we in general like to organize > data models? > > - In the following text, is the right verb exchanged or announced? > > Minimally must contain the same capabilities exchanged during > session setup. > > If a device reports more than announced during the session setup, > how can I actually find out what has been announced for a given > session? Is the idea that an implementation can have capabilities > that are only announced on some session?? > > - Several of the elements (e.g. transport, protocol) are just strings > - so how do we achieve interoperability? > > - The description of sourceIdentifier is inconsistent with the XSD. > > - Can you you refer to inet:ip-address in the XSD?? > > - Where are things such as netconf:SessionId or netconf:configNameType > or netconf:filterInlineType defined? Is there a common > capitalization rule for identifiers or is this just random? > > - I read: > > sessionId: > unique identifier for the notifications. Same value as returned in > 'sessions' to allow correlation. > > I assume sessionId is an identifier for the notification session, not > for the notifications... > > - What is NetconfSubscriptionInfo?? And how does it map to "event > subscriptions"? > > - I don't find any of the schema reporting stuff in the XSD. > > - I read: > > location: > a location from which the schema can be retrieved. Can be either on > the network device (eg: URL), retrievable explicitly via netconf > ('netconf') or some network location (eg: URL). > > What is the difference between a 'network device' and a 'network > location'?? > > - Section 3 is all about "will be" but not about how things are > actually done. > > - I read: > > and elements are > mandatory and their values are unique > > It is unclear what specifically is going to be unique. All the > identifers? All version numbers? The combinations of identifiers > with version numbers? Something else? > > - Is there concensus that we do access control in units of schemas? > > - How do I actually retrieve a schema via NETCONF? I know what to do > with a URL but this is where it ends... > > - The list-schema example is not even valid XML. I am missing a clear > definition of the proposed NETCONF capability. And whay is > list-schema good for - it seems to do the same as the get operation, > no? > > - I suggest to remove the first paragraph of section 4 since this text > is also in the security considerations (where it belongs). > > - There needs to be IANA considerations since you need to allocate at > least a URN. > > - I would love to have an appendix with a YANG module. > > - I did not bother to read the XSD. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf If a device reports more than announced during the session setup, > how can I actually find out what has been announced for a given > session? Is the idea that an implementation can have capabilities > that are only announced on some session?? > > - Several of the elements (e.g. transport, protocol) are just strings > - so how do we achieve interoperability? > > - The description of sourceIdentifier is inconsistent with the XSD. > > - Can you you refer to inet:ip-address in the XSD?? > > - Where are things such as netconf:SessionId or netconf:configNameType > or netconf:filterInlineType defined? Is there a common > capitalization rule for identifiers or is this just random? > > - I read: > > sessionId: > unique identifier for the notifications. Same value as returned in > 'sessions' to allow correlation. > > I assume sessionId is an identifier for the notification session, not > for the notifications... > > - What is NetconfSubscriptionInfo?? And how does it map to "event > subscriptions"? > > - I don't find any of the schema reporting stuff in the XSD. > > - I read: > > location: > a location from which the schema can be retrieved. Can be either on > the network device (eg: URL), retrievable explicitly via netconf > ('netconf') or some network location (eg: URL). > > What is the difference between a 'network device' and a 'network > location'?? > > - Section 3 is all about "will be" but not about how things are > actually done. > > - I read: > > and elements are > mandatory and their values are unique > > It is unclear what specifically is going to be unique. All the > identifers? All version numbers? The combinations of identifiers > with version numbers? Something else? > > - Is there concensus that we do access control in units of schemas? > > - How do I actually retrieve a schema via NETCONF? I know what to do > with a URL but this is where it ends... > > - The list-schema example is not even valid XML. I am missing a clear > definition of the proposed NETCONF capability. And whay is > list-schema good for - it seems to do the same as the get operation, > no? > > - I suggest to remove the first paragraph of section 4 since this text > is also in the security considerations (where it belongs). > > - There needs to be IANA considerations since you need to allocate at > least a URN. > > - I would love to have an appendix with a YANG module. > > - I did not bother to read the XSD. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Mar 18 03:13:28 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41AC3A6EF2; Tue, 18 Mar 2008 03:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.168 X-Spam-Level: X-Spam-Status: No, score=-101.168 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH4Jhxkjgaf1; Tue, 18 Mar 2008 03:13:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAEAB3A6BD4; Tue, 18 Mar 2008 03:13:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EE43A6BD4 for ; Tue, 18 Mar 2008 03:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NgrEiSBa8gN for ; Tue, 18 Mar 2008 03:13:26 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 2CFAA3A6781 for ; Tue, 18 Mar 2008 03:13:26 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m2IB7v3G381038; Tue, 18 Mar 2008 11:07:59 GMT Message-ID: <47DF9516.3080401@isima.fr> Date: Tue, 18 Mar 2008 11:10:30 +0100 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: netconf@ietf.org, j.schoenwaelder@jacobs-university.de References: <20080310153309.GB17320@elstar.local> In-Reply-To: <20080310153309.GB17320@elstar.local> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 18 Mar 2008 11:07:59 +0000 (WET) Subject: Re: [Netconf] review of draft-ietf-netconf-tls-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Juergen, Thank you for your comments. Please see comments in-line.. > When the NETCONF peer processes a closure request of the > NETCONF connection, it MUST send a TLS close_notify alert before > closing the connection. > > The phrase "processes a closure request of the NETCONF connection" > sounds fuzzy to me. Perhaps you mean this: > > When the NETCONF peer closes the NETCONF connection, it MUST send > a TLS close_notify alert before closing the TCP connection. OK, I will adopt this text. > I note that there might be cases where this is not possible, e.g. > the peer is dying before if gets to say good bye. > IMO, it is application behavior, RFC 4741 says: "The session closure may be explicitly performed by the client, or implicitly performed by the server based on criteria such as failure of the underlying transport, or simple inactivity timeout. This criteria is dependent on the implementation and the underlying transport." > - I read: > > Unless some other fatal alert has been transmitted, ... > > Who is transmitting a fatal alert to whom and how? Perhaps you mean: > > Unless a fatal error has occured, ... Yes. And fatat alert may be sent by both of the agent and the manager. > > - What is the 'write side' of a connection? RFC4346 uses this terminology of read and the write directions and sides. Each entity has a write and read buffers. When a close is sent by an entity, the entity will close the write buffer (write side of the connection), meaning that it will not send more data over the TLS session. > > - Second sentence in section 3. seems to be garbled. It is replaced with This document specifies how to use TLS with endpoint authentication, which can be based on either preshared keys [RFC4279] or public key certificates [RFC4346]. > > - Can the password based authentication scheme be hooked into RADIUS? > For the momenet it doesn't, and this was the discussion in last meeting. I hope we can move forward with one of the presented options. > /js Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Mar 18 03:13:28 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41AC3A6EF2; Tue, 18 Mar 2008 03:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.168 X-Spam-Level: X-Spam-Status: No, score=-101.168 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH4Jhxkjgaf1; Tue, 18 Mar 2008 03:13:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAEAB3A6BD4; Tue, 18 Mar 2008 03:13:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EE43A6BD4 for ; Tue, 18 Mar 2008 03:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NgrEiSBa8gN for ; Tue, 18 Mar 2008 03:13:26 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 2CFAA3A6781 for ; Tue, 18 Mar 2008 03:13:26 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m2IB7v3G381038; Tue, 18 Mar 2008 11:07:59 GMT Message-ID: <47DF9516.3080401@isima.fr> Date: Tue, 18 Mar 2008 11:10:30 +0100 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: netconf@ietf.org, j.schoenwaelder@jacobs-university.de References: <20080310153309.GB17320@elstar.local> In-Reply-To: <20080310153309.GB17320@elstar.local> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 18 Mar 2008 11:07:59 +0000 (WET) Subject: Re: [Netconf] review of draft-ietf-netconf-tls-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Juergen, Thank you for your comments. Please see comments in-line.. > When the NETCONF peer processes a closure request of the > NETCONF connection, it MUST send a TLS close_notify alert before > closing the connection. > > The phrase "processes a closure request of the NETCONF connection" > sounds fuzzy to me. Perhaps you mean this: > > When the NETCONF peer closes the NETCONF connection, it MUST send > a TLS close_notify alert before closing the TCP connection. OK, I will adopt this text. > I note that there might be cases where this is not possible, e.g. > the peer is dying before if gets to say good bye. > IMO, it is application behavior, RFC 4741 says: "The session closure may be explicitly performed by the client, or implicitly performed by the server based on criteria such as failure of the underlying transport, or simple inactivity timeout. This criteria is dependent on the implementation and the underlying transport." > - I read: > > Unless some other fatal alert has been transmitted, ... > > Who is transmitting a fatal alert to whom and how? Perhaps you mean: > > Unless a fatal error has occured, ... Yes. And fatat alert may be sent by both of the agent and the manager. > > - What is the 'write side' of a connection? RFC4346 uses this terminology of read and the write directions and sides. Each entity has a write and read buffers. When a close is sent by an entity, the entity will close the write buffer (write side of the connection), meaning that it will not send more data over the TLS session. > > - Second sentence in section 3. seems to be garbled. It is replaced with This document specifies how to use TLS with endpoint authentication, which can be based on either preshared keys [RFC4279] or public key certificates [RFC4346]. > > - Can the password based authentication scheme be hooked into RADIUS? > For the momenet it doesn't, and this was the discussion in last meeting. I hope we can move forward with one of the presented options. > /js Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Mar 18 03:59:24 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6A028C51C; Tue, 18 Mar 2008 03:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.89 X-Spam-Level: X-Spam-Status: No, score=-100.89 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rsyC1YIBxNU; Tue, 18 Mar 2008 03:59:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A755428C44F; Tue, 18 Mar 2008 03:59:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CE228C48A for ; Tue, 18 Mar 2008 03:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGDfTnF2EBpX for ; Tue, 18 Mar 2008 03:59:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 71EE628C3FC for ; Tue, 18 Mar 2008 03:59:20 -0700 (PDT) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C88D8C831; Tue, 18 Mar 2008 11:57:03 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02259-04; Tue, 18 Mar 2008 11:57:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EE198C824; Tue, 18 Mar 2008 11:57:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C8585510D4D; Tue, 18 Mar 2008 11:57:01 +0100 (CET) Date: Tue, 18 Mar 2008 11:57:01 +0100 From: Juergen Schoenwaelder To: Mohamad Badra Message-ID: <20080318105701.GA22996@elstar.local> Mail-Followup-To: Mohamad Badra , netconf@ietf.org References: <20080310153309.GB17320@elstar.local> <47DF9516.3080401@isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <47DF9516.3080401@isima.fr> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-tls-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, Mar 18, 2008 at 11:10:30AM +0100, Mohamad Badra wrote: >> - I read: >> >> Unless some other fatal alert has been transmitted, ... >> >> Who is transmitting a fatal alert to whom and how? Perhaps you mean: >> >> Unless a fatal error has occured, ... > > Yes. And fatat alert may be sent by both of the agent and the manager. > >> >> - What is the 'write side' of a connection? > > RFC4346 uses this terminology of read and the write directions and sides. > Each entity has a write and read buffers. When a close is sent by an > entity, the entity will close the write buffer (write side of the > connection), meaning that it will not send more data over the TLS session. I guess it will help readers if you make it clear where you use TLS specific terms and where the definition of these terms can be found. I at least got confused by terminology issues. /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 netconf-bounces@ietf.org Tue Mar 18 03:59:24 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6A028C51C; Tue, 18 Mar 2008 03:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.89 X-Spam-Level: X-Spam-Status: No, score=-100.89 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rsyC1YIBxNU; Tue, 18 Mar 2008 03:59:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A755428C44F; Tue, 18 Mar 2008 03:59:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CE228C48A for ; Tue, 18 Mar 2008 03:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGDfTnF2EBpX for ; Tue, 18 Mar 2008 03:59:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 71EE628C3FC for ; Tue, 18 Mar 2008 03:59:20 -0700 (PDT) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C88D8C831; Tue, 18 Mar 2008 11:57:03 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02259-04; Tue, 18 Mar 2008 11:57:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EE198C824; Tue, 18 Mar 2008 11:57:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C8585510D4D; Tue, 18 Mar 2008 11:57:01 +0100 (CET) Date: Tue, 18 Mar 2008 11:57:01 +0100 From: Juergen Schoenwaelder To: Mohamad Badra Message-ID: <20080318105701.GA22996@elstar.local> Mail-Followup-To: Mohamad Badra , netconf@ietf.org References: <20080310153309.GB17320@elstar.local> <47DF9516.3080401@isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <47DF9516.3080401@isima.fr> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-tls-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, Mar 18, 2008 at 11:10:30AM +0100, Mohamad Badra wrote: >> - I read: >> >> Unless some other fatal alert has been transmitted, ... >> >> Who is transmitting a fatal alert to whom and how? Perhaps you mean: >> >> Unless a fatal error has occured, ... > > Yes. And fatat alert may be sent by both of the agent and the manager. > >> >> - What is the 'write side' of a connection? > > RFC4346 uses this terminology of read and the write directions and sides. > Each entity has a write and read buffers. When a close is sent by an > entity, the entity will close the write buffer (write side of the > connection), meaning that it will not send more data over the TLS session. I guess it will help readers if you make it clear where you use TLS specific terms and where the definition of these terms can be found. I at least got confused by terminology issues. /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 netconf-bounces@ietf.org Thu Mar 27 02:49:15 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A183A6D67; Thu, 27 Mar 2008 02:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.403 X-Spam-Level: X-Spam-Status: No, score=-100.403 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Veq17ctMFtoJ; Thu, 27 Mar 2008 02:49:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D423A6AAE; Thu, 27 Mar 2008 02:49:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00CF3A69C5 for ; Thu, 27 Mar 2008 02:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG35Toxmoh8t for ; Thu, 27 Mar 2008 02:49:11 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 44FE128C352 for ; Thu, 27 Mar 2008 02:49:11 -0700 (PDT) Received: (qmail 2855 invoked from network); 27 Mar 2008 09:46:50 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 27 Mar 2008 09:46:50 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Thu, 27 Mar 2008 10:46:50 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] FW: DISCUSS: draft-ietf-netconf-notification X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Forwarding this to the WG list, so everyone can see what sort of DISCUSSes we are getting from IESG and what our responses are. Sharon, I have prefixed the actual comment lines with a ">" sign, so it is easier to see what were the comments and what are your answers. All, We have received more comments (will follow in more postings) So we need to check it all. It seems that we may need another revision of the document to address all comments received sofar. Sharon, can you start preparing text for the security considerations section that we can then propose to the IESG as a resolution. I suggest that you share that with us on the WG mailing list and with Tim, so we can get consensus on th text before we actually do a new revision of the document. send Bert Wijnen ----- Original ----- From: Sharon Chisholm [mailto:schishol@nortel.com] Sent: donderdag 27 maart 2008 3:31 To: Tim Polk; iesg@ietf.org CC: netconf-chairs@tools.ietf.org; draft-ietf-netconf-notification@tools.ietf.org; htrevino@cisco.com; bertietf@bwijnen.net Subject: RE: DISCUSS: draft-ietf-netconf-notification Hi Here are my responses. I believe I addressed the other issues From netconf-bounces@ietf.org Thu Mar 27 02:49:15 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A183A6D67; Thu, 27 Mar 2008 02:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.403 X-Spam-Level: X-Spam-Status: No, score=-100.403 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Veq17ctMFtoJ; Thu, 27 Mar 2008 02:49:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D423A6AAE; Thu, 27 Mar 2008 02:49:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00CF3A69C5 for ; Thu, 27 Mar 2008 02:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG35Toxmoh8t for ; Thu, 27 Mar 2008 02:49:11 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 44FE128C352 for ; Thu, 27 Mar 2008 02:49:11 -0700 (PDT) Received: (qmail 2855 invoked from network); 27 Mar 2008 09:46:50 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 27 Mar 2008 09:46:50 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Thu, 27 Mar 2008 10:46:50 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] FW: DISCUSS: draft-ietf-netconf-notification X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Forwarding this to the WG list, so everyone can see what sort of DISCUSSes we are getting from IESG and what our responses are. Sharon, I have prefixed the actual comment lines with a ">" sign, so it is easier to see what were the comments and what are your answers. All, We have received more comments (will follow in more postings) So we need to check it all. It seems that we may need another revision of the document to address all comments received sofar. Sharon, can you start preparing text for the security considerations section that we can then propose to the IESG as a resolution. I suggest that you share that with us on the WG mailing list and with Tim, so we can get consensus on th text before we actually do a new revision of the document. send Bert Wijnen ----- Original ----- From: Sharon Chisholm [mailto:schishol@nortel.com] Sent: donderdag 27 maart 2008 3:31 To: Tim Polk; iesg@ietf.org CC: netconf-chairs@tools.ietf.org; draft-ietf-netconf-notification@tools.ietf.org; htrevino@cisco.com; bertietf@bwijnen.net Subject: RE: DISCUSS: draft-ietf-netconf-notification Hi Here are my responses. I believe I addressed the other issues in a separate email, but I've include and edited those response here now for completeness. The text is written as a response to the discuss, but can be turned easily into text for the security considerations section of the document. >1. "In Section 7, Security Considerations, the document states: > > It is recommended that care be taken to secure execution: > > o invocation > > o on read-only data models > > o content > >First, what does "secure execution of" mean? I expected the subsequent >text to elaborate on the intent for each of the bulleted items, but >there wasn't a very clear linkage." Secure execution means ensuring that a secure transport is used (SSH, or using HTTPS with SOAP or Beep transport mappings) as well as ensuring that the user has sufficient authorization to perform the function they are requesting against the specific bit of NETCONF content involved. This has the same meaning as it did in the base protocol, which I suspect is why we did not elaborate. may be filtered, in the sense that some users may get access to a subset of the data and different users may get access to different subsets. is like a deferred , and the data that different users can access may vary (probably with the same rules as apply to ). This different access is reflected in the that different users are able to subscribe to >2. "Second, why isn't important to secure execution of on > read-write data models? Are we really referring to retrieving the > list of supported event streams?" It is important to secure the because the name of the streams may provide information about the system such as what services are available on the box, or what other customers getting service from the box, which may be sensitive. >3. "Is there a risk of sessions accumulating? That is, too many > create-subscription requests without termination?" The subscription terminates when the underlying NETCONF session goes way. In order to accumulate subscriptions, you need to accumulate NETCONF sessions. These may well be a finite resource, but the base protocol provides a command to kill a particular session from another session if there is an issue. >4. "How important is the accuracy of the eventTime field for > notification nodes? > If you put in something that doesn't parse, or that's deliberately > bad, is that a problem?" The eventTime field provides the time the event occurred within the network element. If it was corrupted, the NETCONF client would need to detect this and substitute the time the event was received on the client side, which is less then ideal as often the client needs to understand the correct order that events occurred in order to correlate. Note a corruption could easily be detected by either the timestamp making no sense or being different then the expected difference between NE time and NETCONF client time. I don't think this scenario is more likely then any other piece of data being corrupted though. >5. "The filtering and the complexity associated with arbitrary XPath > syntax for specifying filter criteria concerns me. Is there any > risk of someone gaming the events to elude the filter criteria? > Any case matching rules that might need to be specified or > anything like that?" We did not introduce the XPATH mechanism, just applied it to notifications so we are not introducing any new risks that are not in the base protocol. I can't think of any expressions that would be problematic, but I'm not familiar with the more complex XPath syntax. I'm also not exactly sure what 'gaming the events to elude the filter criteria means'. If you mean to use it to get access to events that you should not have access to, since the implementations would be applying access control to the resulting events, not the Xpath expression, I don't think this is an issue. Sharon _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.orgin a separate email, but I've include and edited those response here now for completeness. The text is written as a response to the discuss, but can be turned easily into text for the security considerations section of the document. >1. "In Section 7, Security Considerations, the document states: > > It is recommended that care be taken to secure execution: > > o invocation > > o on read-only data models > > o content > >First, what does "secure execution of" mean? I expected the subsequent >text to elaborate on the intent for each of the bulleted items, but >there wasn't a very clear linkage." Secure execution means ensuring that a secure transport is used (SSH, or using HTTPS with SOAP or Beep transport mappings) as well as ensuring that the user has sufficient authorization to perform the function they are requesting against the specific bit of NETCONF content involved. This has the same meaning as it did in the base protocol, which I suspect is why we did not elaborate. may be filtered, in the sense that some users may get access to a subset of the data and different users may get access to different subsets. is like a deferred , and the data that different users can access may vary (probably with the same rules as apply to ). This different access is reflected in the that different users are able to subscribe to >2. "Second, why isn't important to secure execution of on > read-write data models? Are we really referring to retrieving the > list of supported event streams?" It is important to secure the because the name of the streams may provide information about the system such as what services are available on the box, or what other customers getting service from the box, which may be sensitive. >3. "Is there a risk of sessions accumulating? That is, too many > create-subscription requests without termination?" The subscription terminates when the underlying NETCONF session goes way. In order to accumulate subscriptions, you need to accumulate NETCONF sessions. These may well be a finite resource, but the base protocol provides a command to kill a particular session from another session if there is an issue. >4. "How important is the accuracy of the eventTime field for > notification nodes? > If you put in something that doesn't parse, or that's deliberately > bad, is that a problem?" The eventTime field provides the time the event occurred within the network element. If it was corrupted, the NETCONF client would need to detect this and substitute the time the event was received on the client side, which is less then ideal as often the client needs to understand the correct order that events occurred in order to correlate. Note a corruption could easily be detected by either the timestamp making no sense or being different then the expected difference between NE time and NETCONF client time. I don't think this scenario is more likely then any other piece of data being corrupted though. >5. "The filtering and the complexity associated with arbitrary XPath > syntax for specifying filter criteria concerns me. Is there any > risk of someone gaming the events to elude the filter criteria? > Any case matching rules that might need to be specified or > anything like that?" We did not introduce the XPATH mechanism, just applied it to notifications so we are not introducing any new risks that are not in the base protocol. I can't think of any expressions that would be problematic, but I'm not familiar with the more complex XPath syntax. I'm also not exactly sure what 'gaming the events to elude the filter criteria means'. If you mean to use it to get access to events that you should not have access to, since the implementations would be applying access control to the resulting events, not the Xpath expression, I don't think this is an issue. Sharon _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf /mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Mar 27 03:08:00 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D004C28C858; Thu, 27 Mar 2008 03:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.442 X-Spam-Level: X-Spam-Status: No, score=-100.442 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-ZnI0QNKw9B; Thu, 27 Mar 2008 03:08:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEC628C352; Thu, 27 Mar 2008 03:07:59 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1EB628C500 for ; Thu, 27 Mar 2008 03:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOWi+u6kTeoK for ; Thu, 27 Mar 2008 03:07:57 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 663CF28C2CA for ; Thu, 27 Mar 2008 03:07:57 -0700 (PDT) Received: (qmail 28268 invoked from network); 27 Mar 2008 10:05:36 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 27 Mar 2008 10:05:36 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Thu, 27 Mar 2008 11:05:36 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] FW: [secdir] secdir review of draft-ietf-netconf-notification-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Here are Sharon's responses to review comments from the security directorate. Bert Wijnen -----Original Message----- From: Blake Ramsdell [mailto:blake@sendmail.com] Sent: Sunday, March 23, 2008 8:18 PM To: iesg@ietf.org; secdir@mit.edu; Chisholm, Sharon (CAR:ZZ00); htrevino@cisco.com Subject: Re: [secdir] secdir review of draft-ietf-netconf-notification-12 On Tue, Mar 04, 2008 at 07:47:43PM -0800, Blake Ramsdell wrote: > * Is there a risk of sessions accumulating? That is, too many > create-subscription requests without termination? The subscription terminates when the underlying NETCONF session goes way. In order to accumulate subscriptions, you need to accumulate NETCONF sessions. These may well be a finite resource, but the base protocol provides a command to kill a particular session from another session if there is an issue. > > * How important is the accuracy of the eventTime field for notification nodes? > If you put in something that doesn't parse, or that's deliberately bad, is > that a problem? The eventTime field provides the time the event occurred within the network element. If it was corrupted, the NETCONFrom netconf-bounces@ietf.org Thu Mar 27 03:08:00 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D004C28C858; Thu, 27 Mar 2008 03:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.442 X-Spam-Level: X-Spam-Status: No, score=-100.442 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-ZnI0QNKw9B; Thu, 27 Mar 2008 03:08:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEC628C352; Thu, 27 Mar 2008 03:07:59 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1EB628C500 for ; Thu, 27 Mar 2008 03:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOWi+u6kTeoK for ; Thu, 27 Mar 2008 03:07:57 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 663CF28C2CA for ; Thu, 27 Mar 2008 03:07:57 -0700 (PDT) Received: (qmail 28268 invoked from network); 27 Mar 2008 10:05:36 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 27 Mar 2008 10:05:36 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Thu, 27 Mar 2008 11:05:36 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] FW: [secdir] secdir review of draft-ietf-netconf-notification-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Here are Sharon's responses to review comments from the security directorate. Bert Wijnen -----Original Message----- From: Blake Ramsdell [mailto:blake@sendmail.com] Sent: Sunday, March 23, 2008 8:18 PM To: iesg@ietf.org; secdir@mit.edu; Chisholm, Sharon (CAR:ZZ00); htrevino@cisco.com Subject: Re: [secdir] secdir review of draft-ietf-netconf-notification-12 On Tue, Mar 04, 2008 at 07:47:43PM -0800, Blake Ramsdell wrote: > * Is there a risk of sessions accumulating? That is, too many > create-subscription requests without termination? The subscription terminates when the underlying NETCONF session goes way. In order to accumulate subscriptions, you need to accumulate NETCONF sessions. These may well be a finite resource, but the base protocol provides a command to kill a particular session from another session if there is an issue. > > * How important is the accuracy of the eventTime field for notification nodes? > If you put in something that doesn't parse, or that's deliberately bad, is > that a problem? The eventTime field provides the time the event occurred within the network element. If it was corrupted, the NETCONF client would need to substitute the time the event was received on the client side, which is less then ideal as often the client needs to understand the order that events occurred in order to correlate. So, there is a workaround if this were to happen, but I'm not sure how likely it is. > > * The filtering and the complexity associated with arbitrary XPath syntax for > specifying filter criteria concerns me. Is there any risk of someone gaming > the events to elude the filter criteria? Any case matching rules that might > need to be specified or anything like that? We did not introduce the XPATH mechanism, just applied it to notifications so we are not introducing any new risks that are not in the base protocol. I can't think of any expressions that would be problematic, but I'm not familiar with the more complex XPath syntax. I'm also not exactly sure what 'gaming the events to elude the filter criteria means'. If you mean to use it to get access to events that you should not have access to, since the implementations would be applying access control to the resulting events, not the xpath expression, I don't think this is an issue. Sharon _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf F client would need to substitute the time the event was received on the client side, which is less then ideal as often the client needs to understand the order that events occurred in order to correlate. So, there is a workaround if this were to happen, but I'm not sure how likely it is. > > * The filtering and the complexity associated with arbitrary XPath syntax for > specifying filter criteria concerns me. Is there any risk of someone gaming > the events to elude the filter criteria? Any case matching rules that might > need to be specified or anything like that? We did not introduce the XPATH mechanism, just applied it to notifications so we are not introducing any new risks that are not in the base protocol. I can't think of any expressions that would be problematic, but I'm not familiar with the more complex XPath syntax. I'm also not exactly sure what 'gaming the events to elude the filter criteria means'. If you mean to use it to get access to events that you should not have access to, since the implementations would be applying access control to the resulting events, not the xpath expression, I don't think this is an issue. Sharon _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Mar 27 08:34:03 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1F53A6FF9; Thu, 27 Mar 2008 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.977 X-Spam-Level: X-Spam-Status: No, score=-100.977 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So354UoEbpa3; Thu, 27 Mar 2008 08:34:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED4D3A6FBB; Thu, 27 Mar 2008 08:34:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC0628C1F4 for ; Thu, 27 Mar 2008 08:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWMYU9S0h1Fa for ; Thu, 27 Mar 2008 08:33:57 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 116443A6DBA for ; Thu, 27 Mar 2008 08:33:56 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m2RFVVpZ006121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 16:31:31 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m2RFVTim024309; Thu, 27 Mar 2008 16:31:29 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Mar 2008 16:31:29 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8901F.8D33B0C4" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 27 Mar 2008 16:30:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf session at IETF 71 - Preliminary minutes Thread-Index: AciQH4xZE3IGYmtEStu5MRTiDeeJsw== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 27 Mar 2008 15:31:29.0288 (UTC) FILETIME=[A099D080:01C8901F] Subject: [Netconf] Netconf session at IETF 71 - Preliminary minutes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8901F.8D33B0C4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8901F.8D33B0C4" ------_=_NextPart_002_01C8901F.8D33B0C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, attached are the draft minutes we have merged so far=20 from the notes of the minute takers (many thanks again=20 to David P. and Juergen for taking notes!! :). <>=20 Please send us your change requestsFrom netconf-bounces@ietf.org Thu Mar 27 08:34:03 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1F53A6FF9; Thu, 27 Mar 2008 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.977 X-Spam-Level: X-Spam-Status: No, score=-100.977 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So354UoEbpa3; Thu, 27 Mar 2008 08:34:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED4D3A6FBB; Thu, 27 Mar 2008 08:34:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC0628C1F4 for ; Thu, 27 Mar 2008 08:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWMYU9S0h1Fa for ; Thu, 27 Mar 2008 08:33:57 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 116443A6DBA for ; Thu, 27 Mar 2008 08:33:56 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m2RFVVpZ006121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 16:31:31 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m2RFVTim024309; Thu, 27 Mar 2008 16:31:29 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Mar 2008 16:31:29 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8901F.8D33B0C4" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 27 Mar 2008 16:30:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf session at IETF 71 - Preliminary minutes Thread-Index: AciQH4xZE3IGYmtEStu5MRTiDeeJsw== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 27 Mar 2008 15:31:29.0288 (UTC) FILETIME=[A099D080:01C8901F] Subject: [Netconf] Netconf session at IETF 71 - Preliminary minutes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8901F.8D33B0C4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8901F.8D33B0C4" ------_=_NextPart_002_01C8901F.8D33B0C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, attached are the draft minutes we have merged so far=20 from the notes of the minute takers (many thanks again=20 to David P. and Juergen for taking notes!! :). <>=20 Please send us your change requests or corrections=20 by 10th of April. I'll put it also the meeting materials=20 site as the preliminary version. Thank you. Bert & Mehmet ------_=_NextPart_002_01C8901F.8D33B0C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Netconf session at IETF 71 - Preliminary minutes

Hi All,

attached are the draft minutes we = have merged so far
from the notes of the minute takers = (many thanks again
to David P. and Juergen for taking = notes!! :).

<<Netconf_IETF = 71_Draft_minutes.txt>>

Please send us your change requests = or corrections
by 10th of April. I'll put it also = the meeting materials
site as the preliminary = version.

Thank you.

Bert & Mehmet

------_=_NextPart_002_01C8901F.8D33B0C4-- ------_=_NextPart_001_01C8901F.8D33B0C4 Content-Type: text/plain; name="Netconf_IETF 71_Draft_minutes.txt" Content-Transfer-Encoding: base64 Content-Description: Netconf_IETF 71_Draft_minutes.txt Content-Disposition: attachment; filename="Netconf_IETF 71_Draft_minutes.txt" LS0tIFBSRUxJTUlOQVJZIC0gTWFyY2ggMjcsIDIwMDgtLS0NCg0KTmV0d29yayBDb25maWd1cmF0 aW9uIFdHIFNlc3Npb24gYXQgdGhlIElFVEYgIzcxIA0KTU9OREFZLCBNYXJjaCAxMCwgMjAwOCAx NzQwLTE5NTANCg0KQ2hhaXJzOiBCZXJ0IFdpam5lbiwgTWVobWV0IEVyc3VlDQpBRDogRGFuIFJv bWFzY2FudQ0KDQpNaW51dGUgVGFrZXJzOg0KRGF2aWQgUGFydGFpbiwgSnVlcmdlbiBTY2hvZW53 YWVsZGVyDQoNCkFnZW5kYSBhbmQgV0cgc3RhdHVzIHNsaWRlczogaHR0cDovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy8wOG1hci9zbGlkZXMvbmV0Y29uZi0wLnBwdA0KDQpBZ2VuZGEgYmFzaGlu ZyAtIEFkZGVkIE1hcmsncyBwcmVzZW50YXRpb24gb24gc2NoZW1hIGFkdmVydGlzZW1lbnQgd29y ayBhZnRlciBjdXJyZW50IGNoYXJ0ZXIgaXRlbXMuDQoNClRoZXJlIHdlcmUgNTAgcGVyc29ucyBp biB0aGUgTkVUQ09ORiBzZXNzaW9uLg0KDQpXRyBzdGF0dXMgcmV2aWV3IGdpdmVuIGJ5IE1laG1l dCBFcnN1ZS4NCk5vdGlmaWNhdGlvbiBkcmFmdCBmaW5hbGl6ZWQgYnkgV0cgd2l0aCBCZXJ0IFdp am5lbiBhcyB0aGUgcHJvdG8gd3JpdGV1cC4gDQpDdXJyZW50IHN0YXR1cyBpczogIklFU0cgRXZh bHVhdGlvbiIsIHdpbGwgYmUgZGlzY3Vzc2VkIG9uIElFVEYgdGVsZWNoYXQgTWFyY2ggMjcuIA0K DQpUaGUgb3BlbiBtaWMgc2Vzc2lvbiB3aWxsIGFsbG93IHBlb3BsZSBpbiB0aGUgTkVUQ09ORiB3 b3JraW5nIGdyb3VwIHRvIHBvaW50IG91dCB3aGF0IHRoZXkgdGhpbmsgdGhlIG1vc3QgaW1wb3J0 YW50IE5FVENPTkYgRGF0YSBNb2RlbGluZyByZXF1aXJlbWVudHMgYXJlLg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk5F VENPTkYgb3ZlciBUTFMgKENoYXJsaWUgS2F1Zm1hbiBvbiBiZWhhbGYgb2YgTW9oYW1hZCBCYWRy YSkNCg0KU2xpZGVzOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzA4bWFyL3NsaWRl cy9uZXRjb25mLTEucHB0DQoNCkRpc2NsYWltZXI6IENoYXJsaWUncyBub3QgdGhhdCBmYW1pbGlh ciB3aXRoIE5FVENPTkYgYnV0IHJlYWQgYW5kIGNvbW1lbnRlZCB0aGUgVExTIGRyYWZ0Lg0KDQpQ U0sgaGFzaGVzIGVuc3VyZXMgdGhhdCBjcmVkZW50aWFscyBzdG9yZWQgb24gYSBzZXJ2ZXIgY2Fu J3QgYmUgc3RvbGVuLg0KDQpUaHJlZSBvcHRpb25zIGZvciB1c2VyIGF1dGhlbnRpY2F0aW9uIHN1 Ym1pdHRlZCB0byBtYWlsaW5nIGxpc3RzOg0KMS4gPHVzZXItbG9naW4+IGlzIHNpbXBsZSB0byBk bywgbXVjaCBsaWtlIG11Y2ggYXV0aGVudGljYXRpb24gdGhhdCBoYXBwZW5zIG9uIHRoZSB3ZWIg YWxsIG9mIHRoZSB0aW1lLiAgU2VydmVyIGlzIGF1dGhlbnRpY2F0ZWQgKGUuZy4sIHVzaW5nIGEg Y2VydGlmaWNhdGUpIGFuZCB0aGVyZWFmdGVyIHRoZSB1c2VyIGxvZ3MgaW4gd2l0aCBhIHVzZXJu YW1lIGFuZCBwYXNzd29yZC4gTWlnaHQgcmFpc2UgcXVlc3Rpb25zIGZyb20gdGhlIHNlY3VyaXR5 IEFEczsgdGVjaG5pY2FsIGRldGFpbCBpcyB0aGF0IE5FVENPTkYgYXNzdW1lcyB0aGUgYXV0aGVu dGljYXRpb24gaXMgcGFydCBvZiB0aGUgdHJhbnNwb3J0IG5vdCBORVRDT05GLg0KMi4gRW5oYW5j ZSBUTFMgc28gdGhhdCB1c2VyIGF1dGhlbnRpY2F0aW9uIGJlY29tZXMgcGFydCBvZiBUTFMsIHdv bid0IGZseSBpbiB0aGUgVExTIGNvbW11bml0eQ0KMy4gUnVubmluZyBCRUVQIG92ZXIgVExTLCBs b29rcyBjb21wbGV4IGZvciBhIHNvbHV0aW9uLCByZXF1aXJlcyB0aGF0IGFsbCBpbXBsZW1lbnRh dGlvbnMgZG8gYWN0dWFsbHkgc3VwcG9ydCBCRUVQDQoNCkVuaGFuY2VkIFRMUzoNCkVrcjogbm8g d2F5Lg0KDQpCRUVQIGRpc2N1c3Npb246DQpROiBJcyBUTFMgb3ZlciBCRUVQIG5vdCByZWR1bmRh bnQ/DQpDaGFybGllOiBUaGUgQkVFUCB0cmFuc3BvcnQgZm9yIFJGQyA0NzQ0IGFscmVhZHkgdGFs a3MgYWJvdXQgdGhlIHBvc3NpYmlsaXR5IHRvIHVzZSB0aGUgVExTIGFuZCBTQVNMIHByb2ZpbGVz IG9mIEJFRVA7IHNvIHRoZSBCRUVQIG92ZXIgVExTIG9wdGlvbiBzZWVtcyB0byBub3QgcmVhbGx5 IGJlIGFuIG9wdGlvbiBhcyBpdCBpcyBhbHJlYWR5IGRlZmluZWQuDQoNCkJlcnQgV2lqbmVuIC0g V291bGQgdGhpcyByZXF1aXJlIGEgQkVFUCBpbXBsZW1lbnRhdGlvbiBvbiB0aGUgY2xpZW50cy4g IEFuc3dlcjogWWVzLiAgDQpCZXJ0OiBzbyB0aGlzIGNvbmZsaWN0cyB3aXRoIHRoZSBnb2FsIG9m IE5FVENPTkYgb3ZlciBUTFMgc2luY2Ugd2UgZG9uJ3Qgd2FudCB0byByZXF1aXJlIHNvbWV0aGlu ZyBhZGRpdGlvbmFsLg0KDQpKdWVyZ2VuIFM6IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBCRUVQ IGFscmVhZHkgcnVucyBvdmVyIFRMUyBpZiB5b3Ugd2FudC4gIElzbid0IHRoZSBwcm9ibGVtIHRo ZXJlYnkgYWxyZWFkeSBzb2x2ZWQ/ICANCkNoYXJsaWU6IGRvbid0IHJlYWxseSBrbm93Lg0KDQo8 cmVxdWVzdC1sb2dpbj4gb25seSB3b3JrcyBmb3IgcGxhaW50ZXh0IHBhc3N3b3JkcywgYnV0IGl0 J3MgcG9zc2libGUgdG8gaW50cm9kdWNlIFNBU0wsIGJ1dCB0aGlzIGhhc24ndCBiZWVuIGRpc2N1 c3NlZCBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KQSBmZXcgcGVvcGxlIGluIHRoZSByb29tIHRob3Vn aHQgdGhhdCBtZXJnaW5nIHRoaXMgd29yayB3aXRoIHRoZSBCRUVQIGRvY3VtZW50IHdhcyBub3Qg YSBnb29kIGlkZWEuICBObyBvbmUga25ldyB3aG8gaGFkIGFkdm9jYXRlZCB0aGlzLg0KDQpROiBJ cyB0aGUgcmVxdWlyZW1lbnQgdG8gcmV1c2UgdGhlIHNhbWUgcG9ydCBmb3IgYSBUTFMgbWFwcGlu ZyBjb21pbmcgZnJvbSB0aGUgc2VjdXJpdHkgYXJlYT8NCkNoYXJsaWUgdGFrZXMgYW4gYWN0aW9u IGl0ZW0gdG8gZmlndXJlIHRoaXMgb3V0Lg0KDQpROiBJcyBpdCBub3QgYSByZXF1aXJlbWVudCB0 aGF0IHdlIGNhbiBob29rIGludG8gZXhpc3RpbmcgYXV0aGVudGljYXRpb24gaW5mcmFzdHJ1Y3R1 cmVzPw0KQ2hhcmxpZTogV2UgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIgdGhlcmUgaXMgYSBy ZXF1aXJlbWVudCB0byBoYXZlIHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIG9yIHdoZXRoZXIgVExT IGNlcnRpZmljYXRlIGF1dGhlbnRpY2F0aW9uIGlzIGdvb2QgZW5vdWdoIGZvciBvdXIgbmVlZHMN Cg0KRGF2aWQgTmVsc29uIGFza3MgYWJvdXQgcmVxdWlyZW1lbnRzIGFib3V0IGJhY2tlbmQgZGF0 YWJhc2VzIHlvdSBleHBlY3QgdG8gdXNlIHRoaXMgd2l0aC4gIFdvcnJpZWQgYWJvdXQgcmVxdWly ZW1lbnRzIHRoYXQgd2lsbCBtZWFuIHRoYXQgd2UgY2FuJ3QgdXNlIGxlZ2FjeSBhdXRoZW50aWNh dGlvbiBzeXN0ZW1zIHN1Y2ggYXMgUkFESVVTLg0KQ2hhcmxpZTogeWVzLCB0aGUgd2F5IHRoaXMg aXMgZGVzaWduZWQgd2lsbCBtZWFuIHRoYXQgeW91IGNhbm5vdCB1c2UgdGhpcyB3aXRoIHRoZXNl IGFsdGVybmF0aXZlcy4NCg0KVGhlcmUgd2FzIGEgYnJpZWYgZGlzY3Vzc2lvbiBhYm91dCBob3cg dGhlIFNTSCB0cmFuc3BvcnQgd29ya3MuDQpOYW1lPz86IHNob3VsZCBTU0ggdHJhbnNwb3J0IGJl IHRoZSBvbmUgeW91IGhhdmUgdG8gdXNlIGlmIHlvdSB3YW50IHBsYWludGV4dCBwYXNzd29yZHMg YW5kIFRMUyBjb3VsZCBiZSB1c2VkIHdoZW4geW91IHdhbnQgbXV0dWFsIGF1dGhlbnRpY2F0aW9u IHdpdGggY2VydGlmaWNhdGVzIGFuZCB0aGUgbGlrZS4NCg0KUGhpbCBTaGFmZXI6IFdoYXQgaXMg dGhlIG1vdGl2YXRpb24gb2YgdGhlIFRMUyB3b3JrPyAgDQpCZXJ0OiBUaGVyZSBhcmUgY2FzZXMg d2hlcmUgVExTIGlzIGRlcGxveWVkIHdpZGVseSBidXQgU1NIIGlzIG5vdC4gIFdlIG1pZ2h0IHRv IGhhdmUgdGhpcyBpbiBtaW5kIHdoZW4gd2UgY2hlY2sgdGhlIHBhc3N3b3JkIGF1dGhlbnRpY2F0 aW9uIHJlcXVpcmVtZW50LiBTbywgdGhpcyBpcyBqdXN0IGFub3RoZXIgdHJhbnNwb3J0Lg0KUGhp bDogU28gdGhlcmUgYXJlIHBsYWNlcyB3aGVyZSB0aGV5IGRvbid0IGltcGxlbWVudCBvdXIgc3Rh bmRhcmQgdHJhbnNwb3J0LCBzbyBob3cgbXVjaCBzeW1wYXRoeSBkbyB3ZSBoYXZlPw0KDQpMYXRl ciBpbiB0aGUgbWVldGluZyB3ZSBjaGVja2VkIG9uIGltcGxlbWVudGF0aW9uIHBsYW5zIChzZWUg YmVsb3cpIGFuZCBpdCBzZWVtcyBubyBvbmUgaW4gdGhlIGF1ZGllbmNlIHdhcyBwbGFubmluZyB0 byBpbXBsZW1lbnQgTmV0Y29uZiBvdmVyIFRMUy4gU28gdGhlIHF1ZXN0aW9uIHRvIGJlIGFza2Vk IGlzOiBEb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gc3RhbmRhcmRpemUuIFNwZWNpZmljYWxseSBnaXZl biBhbGwgdGhlICh5ZXQgdW5yZXNvbHZlZCkgaXNzdWVzIGFzIHBlciBhYm92ZSBwcmVzZW50YXRp b24vZGlzY3Vzc2lvbi4NCldlIHdpbGwgY2hlY2sgdGhpcyBvbiB0aGUgbWFpbGluZyBsaXN0Lg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNClBhcnRpYWwgbG9ja2luZyAoQmFsYXpzIExlbmd5ZWwpDQoNClNsaWRlczogaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wOG1hci9zbGlkZXMvbmV0Y29uZi0yLnBwdA0K DQpXaXRoIHJlc3BlY3QgdG8gZmlyc3Qgc2xpZGUsIFNoYXJvbiBDaGlzaG9sbTogd2UgaGF2ZSB0 byBzdXBwb3J0IHByZS1jb25maWd1cmF0aW9uLiAgQXJlIHdlIG1ha2luZyB0aGF0IGltcG9zc2li bGU/ICANCkJhbGF6czogbm8sIHlvdSBoYXZlIHRvIGRlZmluZSB0aGUgdG9wLWxldmVsIG5vZGUg YW5kIGxvY2sgaXQuDQoNClJhbmR5IFByZXN1aG46IE5vdCBleHBsaWNpdCBpbiB0aGUgZG9jdW1l bnQgdGhhdCBsb2NraW5nIHRoZSBub2RlIGdvdCBhbGwgb2YgaXRzIHN1Ym5vZGVzLiAgSWYgeW91 IGRlbGV0ZSBzb21lIHN1Yi10cmVlIHRoYXQncyBsb2NrZWQsIGNhbiBzb21lb25lIHRoZW4gYWx0 ZXIgaXQ/ICANCkJhbGF6czogTm8sIGFuZCBzaW5jZSBpdCdzIG5vdCBjbGVhciBpbiB0aGUgZHJh ZnQgd2UnbGwgbWFrZSBzdXJlIHdlIHVwZGF0ZSBpdC4NCg0KV3J0IHRvIHdoYXQgdG8gaGF2ZSBh cyBub3JtYXRpdmUgZm9yIG1vZGVsczogQmVydCAtIHNob3VsZG4ndCB0aGUgbm9ybWF0aXZlIG1v ZGVsIGJlIFhTRCBzaW5jZSB0aGF0J3Mgd2hhdCB3ZSBoYXZlIGRvbmUgc28gZmFyPyBCb3RoIGFy ZSBub24tbm9ybWF0aXZlIHRvZGF5LiAgDQpNZWhtZXQ6IG9uZSBvZiB0aGVtIG5lZWRzIHRvIGJl IG5vcm1hdGl2ZS4gIA0KRGFuIFJvbWFzY2FudTogVXNlIHRoZSBYU0Qgc2luY2UgdGhhdCdzIHdo YXQncyB3ZSd2ZSB1c2VkIHNvIGZhciwgcHV0IFlBTkcgaW4gYXMgaW5mb3JtYXRpdmUuIA0KQW5k eSBCaWVybWFuOiBXaGF0IHdvdWxkIGJlIHRoZSBwb2ludCBvZiByZW1vdmluZyB0aGUgWFNEPyAg VGhpcyBpcyBzaW5jZSBCYWxhenMgc3VnZ2VzdGVkIHRoZSBFbmdsaXNoIHRleHQgc2hvdWxkIGJl IG5vcm1hdGl2ZS4gIEFuZHkgb2JqZWN0cyBhbmQgdGhpbmtzIHRoYXQgWFNEIHNob3VsZCBiZSBu b3JtYXRpdmUgc2luY2UgdGhhdCdzIHdoYXQgd2UgaGF2ZS4NCkJhbGF6czogVGhhdCdzIHdoYXQg SSdsbCBkby4NCg0KV2l0aCByZXNwZWN0IHRvIE11bHRpLURhdGFzdG9yZSBsb2NrOg0KRGF2aWQg SGFycmluZ3RvbjogSSBzZW50IHRoZSBxdWVzdGlvbiBiZWNhdXNlIHRoZSBkb2N1bWVudCBzYXlz IGl0IGxvY2tzIG9uZSBvciBtb3JlIGRhdGFzdG9yZXMuICANCkJhbGF6czogSSB3aWxsIHJlbW92 ZSB0aGlzIGZyb20gdGhlIG9wZW4gaXNzdWVzIGFuZCBjaGFuZ2UgaXQgdG8gIm9uZSBvcGVyYXRp b24gbG9ja3Mgb25lIGRhdGFzdG9yZSIuDQoNClNlY3VyaXR5IHNsaWRlOiANCkRhdmlkIFBhcnRh aW46IElzIG1vcmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGV4dCBuZWVkZWQ/IFdobyBzdWdn ZXN0ZWQgaXQgbmVlZHMgdG8gYmUgbW9yZT8NCkJhbGF6czogRGF2aWQgSGFycmluZ3RvbiBhbmQg TWVobWV0IHdlcmUgbWVudGlvbmVkLiAgDQpCZXJ0OiBpc24ndCBwb2ludGluZyBhdCA0NzQxIG9r PyAgDQpEYXZpZCBIYXJyaW5ndG9uOiB0aGVyZSBhcmUgY2FzZXMgdGhhdCBkb24ndCBzZWVtIHRv IGJlIGNvdmVyZWQgc2luY2UgdGhpcyBpcyBub3QgYSBnbG9iYWwgbG9jay4gUGFydGlhbCBsb2Nr aW5nIGlzIGRpZmZlcmVudC4gIA0KQmFsYXpzOiBMb2NrIGV4cHJlc3Npb24gaXMgZXZhbHVhdGVk IHdoZW4gdGhlIGxvY2sgaXMgY3JlYXRlZCBub3Qgd2hlbiBhbiBlZGl0IGV4cHJlc3Npb24gaXMg ZXhlY3V0ZWQuIFdpbGwgYWRkIHNvbWUgdGV4dC4gDQpXZXMgSGFyZGFrZXI6IERvY3VtZW50IGRp ZmZlcmVudGlhdGVzIGJldHdlZW4gYSBnbG9iYWwgbG9jayBhbmQgcGFydGlhbCBsb2NrcyBmb3Ig dGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb25zLiBGb3IgZXhhbXBsZSwgd2hhdCBo YXBwZW5zIGlmIHlvdSBjb3B5IGNhbmRpZGF0ZSB0byBydW5uaW5nIHdoaWxlIGEgcGFydGlhbCBs b2NrIGlzIGhlbGQ/IExvY2tpbmcgZ2l2ZXMgdGhlIGltcHJlc3Npb24gdGhhdCBsb2NraW5nIGdp dmVzIGV4Y2x1c2l2ZSBwb3dlciBhbmQgYWNjZXNzLCBzbyB3ZSBuZWVkIHRvIGRvY3VtZW50IGhv dyBORVRDT05GIG9wZXJhdGlvbnMgYXJlIGFmZmVjdGVkLg0KQmVydDogVGhpcyBzZWVtcyB0byBi ZSBhIGdvb2QgZXhlcmNpc2UuIENvdWxkIHlvdSBwb3N0IHNvbWUgb2YgdGhlc2UgY29uY2VybnMg dG8gdGhlIG1haWxpbmcgbGlzdD8NCldlczogU3VyZS4gIFdlIG5lZWQgYSBtYXRyaXggdGhhdCBj b3ZlcnMgdGhlIHZhcmlvdXMgb3BlcmF0aW9ucyBhbmQgdGhlaXIgaW50ZXJhY3Rpb24uDQoNCkFj Y2VzcyBjb250cm9sIHNsaWRlOiAgDQpCZXJ0OiBJJ20gaGFwcHkgd2l0aCBob3cgeW91IHdvcmRl ZCBpdC4gIEkgdGhpbmsgdGhhdCdzIGdvb2QgZW5vdWdoLiAgSWYgc29tZW9uZSBkaXNhZ3JlZXMg d2l0aCB0aGlzLCBwbGVhc2Ugc2VuZCB0ZXh0LiAgV2UgZG9uJ3Qgd2FudCB0byBibG9jayB0aGlz IGRvY3VtZW50IGJ5IHdhaXRpbmcgZm9yIGFjY2VzcyBjb250cm9sLiAgIA0KRGF2aWQgSGFycmlu Z3RvbjogYXQgb25lIHBvaW50LCB0aGUgZG9jdW1lbnQgc2FpZCB5b3UgaGF2ZSB0byBoYXZlIHJl YWQgcmlnaHRzLiAgDQpCYWxhenM6IEkgYmVsaWV2ZSBpdCBzYXlzICJzb21lIHJpZ2h0cyIuICAN ClNoYXJvbjogaXQgc2hvdWxkIHNheSAieW91IGNhbiBsb2NrIGlmIHlvdSBoYXZlIHN1ZmZpY2ll bnQgcHJpdmlsZWdlcyIuICBXZSBzaG91bGQgbWFrZSBhcyBmZXcgYXNzdW1wdGlvbnMgYXMgcG9z c2libGUgYWJvdXQgYWNjZXNzIGNvbnRyb2wgd2hlbiB3cml0aW5nIHRoaXMgZG9jdW1lbnQuICAN CkFuZHkgQmllcm1hbjoganVzdCBsaWtlIHlvdSBtaWdodCB0YWtlIG91dCBhIGdsb2JhbCBsb2Nr IHRvIGdldCBhIGNvbnNpc3RlbnQgcmVhZCwgeW91IG1pZ2h0IHdhbnQgdG8gZG8gc28gZm9yIHBh cnRpYWwgbG9ja2luZy4NCkFuZHkgQmllcm1hbiBhZ2FpbjogSSBkb24ndCB1bmRlcnN0YW5kIHdo eSB0aGUgc2VjdXJpdHkgaXNzdWVzIGFyZSBkaWZmZXJlbnQgZm9yIHRoaXMgYW5kIGdsb2JhbCBs b2Nrcy4gIA0KQmVydDogV2VzIGhhcyBhbHJlYWR5IGFncmVlZCB0byBzZW5kIHNvbWUgbWFpbCB0 byBkaXNjdXNzIHRoaXMuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS or corrections=20 by 10th of April. I'll put it also the meeting materials=20 site as the preliminary version. Thank you. Bert & Mehmet ------_=_NextPart_002_01C8901F.8D33B0C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Netconf session at IETF 71 - Preliminary minutes

Hi All,

attached are the draft minutes we = have merged so far
from the notes of the minute takers = (many thanks again
to David P. and Juergen for taking = notes!! :).

<<Netconf_IETF = 71_Draft_minutes.txt>>

Please send us your change requests = or corrections
by 10th of April. I'll put it also = the meeting materials
site as the preliminary = version.

Thank you.

Bert & Mehmet

------_=_NextPart_002_01C8901F.8D33B0C4-- ------_=_NextPart_001_01C8901F.8D33B0C4 Content-Type: text/plain; name="Netconf_IETF 71_Draft_minutes.txt" Content-Transfer-Encoding: base64 Content-Description: Netconf_IETF 71_Draft_minutes.txt Content-Disposition: attachment; filename="Netconf_IETF 71_Draft_minutes.txt" LS0tIFBSRUxJTUlOQVJZIC0gTWFyY2ggMjcsIDIwMDgtLS0NCg0KTmV0d29yayBDb25maWd1cmF0 aW9uIFdHIFNlc3Npb24gYXQgdGhlIElFVEYgIzcxIA0KTU9OREFZLCBNYXJjaCAxMCwgMjAwOCAx NzQwLTE5NTANCg0KQ2hhaXJzOiBCZXJ0IFdpam5lbiwgTWVobWV0IEVyc3VlDQpBRDogRGFuIFJv bWFzY2FudQ0KDQpNaW51dGUgVGFrZXJzOg0KRGF2aWQgUGFydGFpbiwgSnVlcmdlbiBTY2hvZW53 YWVsZGVyDQoNCkFnZW5kYSBhbmQgV0cgc3RhdHVzIHNsaWRlczogaHR0cDovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy8wOG1hci9zbGlkZXMvbmV0Y29uZi0wLnBwdA0KDQpBZ2VuZGEgYmFzaGlu ZyAtIEFkZGVkIE1hcmsncyBwcmVzZW50YXRpb24gb24gc2NoZW1hIGFkdmVydGlzZW1lbnQgd29y ayBhZnRlciBjdXJyZW50IGNoYXJ0ZXIgaXRlbXMuDQoNClRoZXJlIHdlcmUgNTAgcGVyc29ucyBp biB0aGUgTkVUQ09ORiBzZXNzaW9uLg0KDQpXRyBzdGF0dXMgcmV2aWV3IGdpdmVuIGJ5IE1laG1l dCBFcnN1ZS4NCk5vdGlmaWNhdGlvbiBkcmFmdCBmaW5hbGl6ZWQgYnkgV0cgd2l0aCBCZXJ0IFdp am5lbiBhcyB0aGUgcHJvdG8gd3JpdGV1cC4gDQpDdXJyZW50IHN0YXR1cyBpczogIklFU0cgRXZh bHVhdGlvbiIsIHdpbGwgYmUgZGlzY3Vzc2VkIG9uIElFVEYgdGVsZWNoYXQgTWFyY2ggMjcuIA0K DQpUaGUgb3BlbiBtaWMgc2Vzc2lvbiB3aWxsIGFsbG93IHBlb3BsZSBpbiB0aGUgTkVUQ09ORiB3 b3JraW5nIGdyb3VwIHRvIHBvaW50IG91dCB3aGF0IHRoZXkgdGhpbmsgdGhlIG1vc3QgaW1wb3J0 YW50IE5FVENPTkYgRGF0YSBNb2RlbGluZyByZXF1aXJlbWVudHMgYXJlLg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk5F VENPTkYgb3ZlciBUTFMgKENoYXJsaWUgS2F1Zm1hbiBvbiBiZWhhbGYgb2YgTW9oYW1hZCBCYWRy YSkNCg0KU2xpZGVzOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzA4bWFyL3NsaWRl cy9uZXRjb25mLTEucHB0DQoNCkRpc2NsYWltZXI6IENoYXJsaWUncyBub3QgdGhhdCBmYW1pbGlh ciB3aXRoIE5FVENPTkYgYnV0IHJlYWQgYW5kIGNvbW1lbnRlZCB0aGUgVExTIGRyYWZ0Lg0KDQpQ U0sgaGFzaGVzIGVuc3VyZXMgdGhhdCBjcmVkZW50aWFscyBzdG9yZWQgb24gYSBzZXJ2ZXIgY2Fu J3QgYmUgc3RvbGVuLg0KDQpUaHJlZSBvcHRpb25zIGZvciB1c2VyIGF1dGhlbnRpY2F0aW9uIHN1 Ym1pdHRlZCB0byBtYWlsaW5nIGxpc3RzOg0KMS4gPHVzZXItbG9naW4+IGlzIHNpbXBsZSB0byBk bywgbXVjaCBsaWtlIG11Y2ggYXV0aGVudGljYXRpb24gdGhhdCBoYXBwZW5zIG9uIHRoZSB3ZWIg YWxsIG9mIHRoZSB0aW1lLiAgU2VydmVyIGlzIGF1dGhlbnRpY2F0ZWQgKGUuZy4sIHVzaW5nIGEg Y2VydGlmaWNhdGUpIGFuZCB0aGVyZWFmdGVyIHRoZSB1c2VyIGxvZ3MgaW4gd2l0aCBhIHVzZXJu YW1lIGFuZCBwYXNzd29yZC4gTWlnaHQgcmFpc2UgcXVlc3Rpb25zIGZyb20gdGhlIHNlY3VyaXR5 IEFEczsgdGVjaG5pY2FsIGRldGFpbCBpcyB0aGF0IE5FVENPTkYgYXNzdW1lcyB0aGUgYXV0aGVu dGljYXRpb24gaXMgcGFydCBvZiB00tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTkVUQ09ORiBNb25pdG9yaW5nIFNjaGVtYSAoTWFy ayBTY290dCkNCg0KU2xpZGVzOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzA4bWFy L3NsaWRlcy9uZXRjb25mLTUucHB0DQoNClNob3VsZCB3ZSBoYXZlIGEgc3BlY2lhbGl6ZWQgKGlu YmFuZCkgZ2V0LXNjaGVtYSA/DQpTb21lIHNlZW0gdG8gd2FudCBpdCwgbmVlZCB0byBmaWd1cmUg b3V0IHdoZXRoZXIgdGhlcmUgaXMgV0cgY29uc2Vuc3VzLg0KU2hhcm9uIENoaXNob2xtOiBJZiB3 ZSBkZWZpbmUgdGhpcyBhcyBwYXJ0IG9mIHRoZSBkYXRhIG1vZGVsLCB0aGVuIHJldHJpZXZpbmcg dGhlIHdob2xlIGNvbnRlbnRzIG9mIHRoZSBkYXRhc3RvcmUgd2lsbCBhbHNvIGdldCB0aGlzLCB3 aGVyZWFzIGEgc3BlY2lhbGl6ZWQgdmVyYiB3b3VsZCBhbGxvdyB1cyB0byBzY29wZS4NClNvIHRo YXQsIHlvdSByZXRyaWV2ZSB0aGUgc2NoZW1hIGRlZmluaXRpb24gdGhlcmUsIGJ1dCBpdCBkb2Vz IG5vdCBzaG93IHVwIGFzIHBhcnQgb2YgeW91ciBvcGVyYXRpb25hbCBhbmQgY29uZmlndXJhdGlv biBkYXRhLg0KTWFyazogWWVzLCBJIHRob3VnaHQgd2UgZG9uJ3QgbmVlZCB0byBrZWVwIHRoZSBy ZWZlcmVuY2VzIHRvIHRoZSBzY2hlbWEgaW4gdGhlIG5vcm1hbGl6ZWQgbW9uaXRvcmluZyBtb2Rl bC4gVGhlIHNjaGVtYSBtaWdodCBiZWNvbWUgbGFyZ2UsIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHNv bWVvbmUgd2FudHMgdG8gZ2V0IGFsbCBvZiB0aGVtLg0KRGF2aWQgSGFycmluZ3RvbjogIFdoeSBk byB3ZSBoYXZlIHRvIGJlIGFibGUgdG8gZG8gdGhpcyB3aXRoIE5FVENPTkYgcmF0aGVyIHRoYW4g c29tZXRoaW5nIGxpa2UgZnRwPyAgDQpNYXJrOiBPcmlnaW5hbGx5IEkgcHJvcG9zZWQgdGhpcyBi dXQgYSBmZXcgcGVvcGxlIGluIHRoZSBsYXN0IG5lZXRpbmcgYW5kIG9uIHRoZSBtYWlsaXN0IHdo byB3YW50ZWQgdG8gYmUgYWJsZSB0byBkbyBzby4NCkJlcnQ6IERvIHRoZSBwZW9wbGUgaGF2ZSBh biBvcGluaW9uIG9uIHRoYXQ/IEkga25vdyB0aGF0IGEgZmV3IHBlb3BsZSBhc2tlZCB0aGlzLiBU aGUgcXVlc3Rpb24gaXMsIGRvIHdlIGhhdmUgY29uc2Vuc3VzIG9uIHRoaXM/DQpFbWlsZSBTdGVm YW4/IEZyYW5jZSBUZWxlY29tOiBSZWdhcmRpbmcgb3BlcmF0aW9uYWwgbmVlZHMgd2hhdCB3ZSBu ZWVkIGlzIHRoZSBjYXBhYmlsaXR5IG9mIGhvdyB0byBnZXQgdGhlIGxpc3Qgb2YgdGhlIHNjaGVt YXMgb2YgYSBkZXZpY2UgYW5kIGhhdmluZyB0aGUgdmVyc2lvbiBvZiB2YXJpb3VzIHNjaGVtYXMg d2hpY2ggYXJlIGN1cnJlbnRseSBpbXBsZW1lbnRlZCBvbiB0aGUgZGV2aWNlLg0KTWFyazogVGhh dCdzIGN1cnJlbnRseSB0aGVyZSwgeW91IGNhbiBkbyBiYXNpY2FsbHkgYSBnZXQgb24gbW9uaXRv cmluZyBkYXRhIGFuZCByZXR1cm4gYSBsaXN0IGlkZW50aWZpZXJzLCB3aGljaCBhcmUgYmFzaWNh bGx5IHRoZSBzY2hlbWEgbmFtZXMgYW5kIHZlcnNpb24gYW5kIGEgbG9jYXRpb24gKHdoaWNoIGlz IGFuIGZ0cCBvciBhIFVSSSkNClBoaWwgU2hhZmVyOiAgSSB3YW50IHRvIGJlIGFibGUgdG8gcmV0 cmlldmUgaXQgdXNpbmcgTkVUQ09ORi4gV2UncmUgcmVpbnZlbnRpbmcgc3R1ZmYsIGJ1dCBJIHdh bnQgaXQuDQpCZXJ0OiBTbywgeW91IHNlZSB0aGUgYmFkIHNpZGUsIGJ1dCB5b3Ugc3RpbGwgd2Fu dCBpdC4gV2UgbmVlZCB0byBnZXQgY29uc2Vuc3VzIG9uIHRoZSBsaXN0Lg0KTWFyazogV2UnZCBv bmx5IGJlIGFibGUgdG8gcmVzcG9uZCB3aXRoIHBsYWludGV4dCBYTUwsIHdoaWNoIGNhbiBiZSBx dWl0ZSB2ZXJib3NlLiAgV2UgbWF5IHdhbnQgdG8gYmUgYWJsZSB0byBnZXQgaXQgaW4gYW5vdGhl ciBmb3JtYXQsIGkuZSBBU0NJSSB2ZXJzaW9uLg0KDQpXZXMgSGFyZGFrZXI6IE9uZSBvZiB0aGUg Y29tcGxhaW50cyBhYm91dCBTTk1QIGlzIHRoYXQgeW91IGNhbm5vdCBnZXQgdGhlIGluZm9ybWF0 aW9uIGFib3V0IGNhcGFiaWxpdGllcy4gQXMgbWFueSBwZW9wbGUgc2FpZCB0aGlzIGlzIG9uZSBv ZiBtaXNlcmFibGUgZmFpbHVyZXMgd2hlcmUgU01JIGRlYWx0IHdpdGggc3R1ZmYgbGlrZSB0aGlz LCB0aGUgYWdlbnQgY2FwYWJpbGl0aWVzIGFuZCByZWZlcnJhbCBkaWRuJ3Qgd29yay4gSWYgdGhl IGRldmljZSB3b3VsZCBqdXN0IHJldHVybiBpdCdzIGFiaWxpdGllcyB0aGF0IHdvdWxkIGJlIGEg Z29vZCB0aGluZy4gVGhhdCdzIGNlcnRhaW5seSBzb21ldGhpbmcgdG8gZG8uIFRoYXQgYmVpbmcg c2FpZCBpZiB5b3UgZG8gcHVibGlzaCB0aGUgc2NoZW1hIGFuZCB5b3UgZG9uJ3QgZG8gaXQgd2l0 aCBhIHNlcGFyYXRlIGNvbW1hbmQsIG1ha2Ugc3VyZSBpdCBpcyBwdWJsaXNoZWQgaW4gYSBzdGFu ZGFyZGl6ZWQgcGF0dGVybiBvciB0cmVlLCBzbyB5b3UgY2FuIGNvbnNpc3RlbnRseSBibG9jayBv ciBhbGxvdyBhY2Nlc3MgdG8gaXQuIA0KDQpCYWxhenMgTGVuZ3llbDogV2lsbCB5b3UgaW5jbHVk ZSBwYXJ0aWFsIGxvY2tpbmc/ICANCk1hcms6IEkgaGF2ZSB0byBmaWd1cmUgb3V0IGhvdyB0byBp bmNsdWRlIGxvY2tpbmcgZmlyc3QsIEkgaGF2ZSBub3RlZCB0byBpbmNsdWRlIHBhcnRpYWwgbG9j a2luZyBhYnNvbHV0ZWx5LiBJdCBvcGVucyB0aGUgc2FtZSBkaXNjdXNzaW9uIGFzIHdpdGggYWNj ZXNzIGNvbnRyb2wuIFNpbWlsYXJseSwgeW91IG1pZ2h0IHdhbnQgbm90IHRvIHJldHVybiBsb2Nr IGluZm9ybWF0aW9uIGZvciB3aGljaCB5b3UgZG9uJ3QgaGF2ZSB0aGUgdmlzaWJpbGl0eS4gV2Ug aGF2ZSB0byBzb3J0IHRoYXQgb3V0Lg0KDQpCYWxhenMgTGVuZ3llbDogWW91IGhhdmUgYSBzdGF0 ZW1lbnQgdGhhdCB0aGUgY2FwYWJpbGl0eSBzaG91bGQgaW5jbHVkZSBtaW5pbWFsbHkgd2hhdCB3 ZW50IGluICJoYWxsbyBleGNoYW5nZSIuIFdoeSBpcyB0aGlzIGRpZmZlcmVudCBmcm9tIHNjaGVt YSByZXRyaWV2YWwsIHdoeSBub3QgZXhhY3RseSB0aGUgc2FtZSBzZXQ/DQpNYXJrOiBXZSBoYaGUgdHJhbnNwb3J0IG5vdCBORVRDT05GLg0KMi4gRW5oYW5j ZSBUTFMgc28gdGhhdCB1c2VyIGF1dGhlbnRpY2F0aW9uIGJlY29tZXMgcGFydCBvZiBUTFMsIHdv bid0IGZseSBpbiB0aGUgVExTIGNvbW11bml0eQ0KMy4gUnVubmluZyBCRUVQIG92ZXIgVExTLCBs b29rcyBjb21wbGV4IGZvciBhIHNvbHV0aW9uLCByZXF1aXJlcyB0aGF0IGFsbCBpbXBsZW1lbnRh dGlvbnMgZG8gYWN0dWFsbHkgc3VwcG9ydCBCRUVQDQoNCkVuaGFuY2VkIFRMUzoNCkVrcjogbm8g d2F5Lg0KDQpCRUVQIGRpc2N1c3Npb246DQpROiBJcyBUTFMgb3ZlciBCRUVQIG5vdCByZWR1bmRh bnQ/DQpDaGFybGllOiBUaGUgQkVFUCB0cmFuc3BvcnQgZm9yIFJGQyA0NzQ0IGFscmVhZHkgdGFs a3MgYWJvdXQgdGhlIHBvc3NpYmlsaXR5IHRvIHVzZSB0aGUgVExTIGFuZCBTQVNMIHByb2ZpbGVz IG9mIEJFRVA7IHNvIHRoZSBCRUVQIG92ZXIgVExTIG9wdGlvbiBzZWVtcyB0byBub3QgcmVhbGx5 IGJlIGFuIG9wdGlvbiBhcyBpdCBpcyBhbHJlYWR5IGRlZmluZWQuDQoNCkJlcnQgV2lqbmVuIC0g V291bGQgdGhpcyByZXF1aXJlIGEgQkVFUCBpbXBsZW1lbnRhdGlvbiBvbiB0aGUgY2xpZW50cy4g IEFuc3dlcjogWWVzLiAgDQpCZXJ0OiBzbyB0aGlzIGNvbmZsaWN0cyB3aXRoIHRoZSBnb2FsIG9m IE5FVENPTkYgb3ZlciBUTFMgc2luY2Ugd2UgZG9uJ3Qgd2FudCB0byByZXF1aXJlIHNvbWV0aGlu ZyBhZGRpdGlvbmFsLg0KDQpKdWVyZ2VuIFM6IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBCRUVQ IGFscmVhZHkgcnVucyBvdmVyIFRMUyBpZiB5b3Ugd2FudC4gIElzbid0IHRoZSBwcm9ibGVtIHRo ZXJlYnkgYWxyZWFkeSBzb2x2ZWQ/ICANCkNoYXJsaWU6IGRvbid0IHJlYWxseSBrbm93Lg0KDQo8 cmVxdWVzdC1sb2dpbj4gb25seSB3b3JrcyBmb3IgcGxhaW50ZXh0IHBhc3N3b3JkcywgYnV0IGl0 J3MgcG9zc2libGUgdG8gaW50cm9kdWNlIFNBU0wsIGJ1dCB0aGlzIGhhc24ndCBiZWVuIGRpc2N1 c3NlZCBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KQSBmZXcgcGVvcGxlIGluIHRoZSByb29tIHRob3Vn aHQgdGhhdCBtZXJnaW5nIHRoaXMgd29yayB3aXRoIHRoZSBCRUVQIGRvY3VtZW50IHdhcyBub3Qg YSBnb29kIGlkZWEuICBObyBvbmUga25ldyB3aG8gaGFkIGFkdm9jYXRlZCB0aGlzLg0KDQpROiBJ cyB0aGUgcmVxdWlyZW1lbnQgdG8gcmV1c2UgdGhlIHNhbWUgcG9ydCBmb3IgYSBUTFMgbWFwcGlu ZyBjb21pbmcgZnJvbSB0aGUgc2VjdXJpdHkgYXJlYT8NCkNoYXJsaWUgdGFrZXMgYW4gYWN0aW9u IGl0ZW0gdG8gZmlndXJlIHRoaXMgb3V0Lg0KDQpROiBJcyBpdCBub3QgYSByZXF1aXJlbWVudCB0 aGF0IHdlIGNhbiBob29rIGludG8gZXhpc3RpbmcgYXV0aGVudGljYXRpb24gaW5mcmFzdHJ1Y3R1 cmVzPw0KQ2hhcmxpZTogV2UgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIgdGhlcmUgaXMgYSBy ZXF1aXJlbWVudCB0byBoYXZlIHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIG9yIHdoZXRoZXIgVExT IGNlcnRpZmljYXRlIGF1dGhlbnRpY2F0aW9uIGlzIGdvb2QgZW5vdWdoIGZvciBvdXIgbmVlZHMN Cg0KRGF2aWQgTmVsc29uIGFza3MgYWJvdXQgcmVxdWlyZW1lbnRzIGFib3V0IGJhY2tlbmQgZGF0 YWJhc2VzIHlvdSBleHBlY3QgdG8gdXNlIHRoaXMgd2l0aC4gIFdvcnJpZWQgYWJvdXQgcmVxdWly ZW1lbnRzIHRoYXQgd2lsbCBtZWFuIHRoYXQgd2UgY2FuJ3QgdXNlIGxlZ2FjeSBhdXRoZW50aWNh dGlvbiBzeXN0ZW1zIHN1Y2ggYXMgUkFESVVTLg0KQ2hhcmxpZTogeWVzLCB0aGUgd2F5IHRoaXMg aXMgZGVzaWduZWQgd2lsbCBtZWFuIHRoYXQgeW91IGNhbm5vdCB1c2UgdGhpcyB3aXRoIHRoZXNl IGFsdGVybmF0aXZlcy4NCg0KVGhlcmUgd2FzIGEgYnJpZWYgZGlzY3Vzc2lvbiBhYm91dCBob3cg dGhlIFNTSCB0cmFuc3BvcnQgd29ya3MuDQpOYW1lPz86IHNob3VsZCBTU0ggdHJhbnNwb3J0IGJl IHRoZSBvbmUgeW91IGhhdmUgdG8gdXNlIGlmIHlvdSB3YW50IHBsYWludGV4dCBwYXNzd29yZHMg YW5kIFRMUyBjb3VsZCBiZSB1c2VkIHdoZW4geW91IHdhbnQgbXV0dWFsIGF1dGhlbnRpY2F0aW9u IHdpdGggY2VydGlmaWNhdGVzIGFuZCB0aGUgbGlrZS4NCg0KUGhpbCBTaGFmZXI6IFdoYXQgaXMg dGhlIG1vdGl2YXRpb24gb2YgdGhlIFRMUyB3b3JrPyAgDQpCZXJ0OiBUaGVyZSBhcmUgY2FzZXMg d2hlcmUgVExTIGlzIGRlcGxveWVkIHdpZGVseSBidXQgU1NIIGlzIG5vdC4gIFdlIG1pZ2h0IHRv IGhhdmUgdGhpcyBpbiBtaW5kIHdoZW4gd2UgY2hlY2sgdGhlIHBhc3N3b3JkIGF1dGhlbnRpY2F0 aW9uIHJlcXVpcmVtZW50LiBTbywgdGhpcyBpcyBqdXN0IGFub3RoZXIgdHJhbnNwb3J0Lg0KUGhp bDogU28gdGhlcmUgYXJlIHBsYWNlcyB3aGVyZSB0aGV5IGRvbid0IGltcGxlbWVudCBvdXIgc3Rh bmRhcmQgdHJhbnNwb3J0LCBzbyBob3cgbXVjaCBzeW1wYXRoeSBkbyB3ZSBoYXZlPw0KDQpMYXRl ciBpbiB0aGUgbWVldGluZyB3ZSBjaGVja2VkIG9uIGltcGxlbWVudGF0aW9uIHBsYW5zIChzZWUg YmVsb3cpIGFuZCBpdCBzZWVtcyBubyBvbmUgaW4gdGhlIGF1ZGllbmNlIHdhcyBwbGFubmluZyB0 byBpbXBsZW1lbnQgTmV0Y29uZiBvdmVyIFRMUy4gU28gdGhlIHF1ZXN0aW9uIHRvIGJlIGFza2Vk IGlzOiBEb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gc3RhbmRhcmRpemUuIFNwZWNpZmljYWxseSBnaXZl biBhbGwgdGhlICh5ZXQgdW5yZXNvbHZlZCkgaXNzdWVzIGFzIHBlciBhYm92ZSBwcmVzZW50YXRp b24vZGlzY3Vzc2lvbi4NCldlIHdpbGwgY2hlY2sgdGhpcyBvbiB0aGUgbWFpbGluZyBsaXN0Lg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNClBhcnRpYWwgbG9ja2luZyAoQmFsYXpzIExlbmd5ZWwpDQoNClNsaWRlczogaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wOG1hci9zbGlkZXMvbmV0Y29uZi0yLnBwdA0K DQpXaXRoIHJlc3BlY3QgdG8gZmlyc3Qgc2xpZGUsIFNXZl IGFuIGV4YW1wbGUgd2hlcmUgd2UgZG9uJ3Qgd2FudCB0byBwdXQgZXZlcnl0aGluZyBpbiB0aGUg Y2FwYWJpbGl0aWVzIGV4Y2hhbmdlIGJlY2F1c2UgYmFzZWQgb24gdGhlIGNvbmZpZ3VyYXRpb24g b2YgdGhlIGJveCBkdXJpbmcgdGhlIHNlc3Npb24gdGhlIHNjaGVtYSB0aGF0IGlzIHJlbGV2YW50 IGNhbiBjaGFuZ2UuIEUuZy4gaWYgSSBlbmFibGUgYSBwYXJ0aWN1bGFyIHR5cGUgb2YgaW50ZXJm YWNlIEkgd2lsbCBub3cgYWR2ZXJ0aXNlIGl0J3Mgc2NoZW1hIGFzIGJlaW5nIHN1cHBvcnRlZCBv biB0aGUgYm94Lg0KDQpROiBEbyB5b3UgcmVwb3J0IHN0YXRlIGFib3V0IHBhcnRpYWwgbG9ja3M/ DQpNYXJrOiBZZXMuDQoNClE6IFdoYXQgaXMgdGhlIHNldCBvZiBtaW5pbWFsbHkgYW5ub3VuY2Vk IGNhcGFiaWxpdGllcz8NCk1hcms6IEl0IG1pZ2h0IGJlIHVzZWZ1bC4uLg0KDQpROiBMb3RzIG9m IGRldGFpbGVkIHF1ZXN0aW9ucyBvdXQgdGhlcmUgc2luY2UgdGhlIGRvY3VtZW50IGlzIHNvbWV0 aW1lcyB2YWd1ZT8NCk1hcms6IFdlIGhhdmUgdG8gd29yayB0aHJvdWdoIHRoZW0uDQoNClE6IENh biB0aGUgZmlsZTogVVJOIG5vdCBiZSB1c2VkIHRvIHJlcG9ydCBhIGxvY2FsbHkgc3RvcmVkIHNj aGVtYT8NCk1hcms6IE1pZ2h0IGJlIHdvcmthYmxlLg0KDQpROiBJcyBzY2hlbWEgYWR2ZXJ0aXNl bWVudCBtYW5kYXRvcnk/IElzIHRoZSBzdG9yYWdlIG9mIHNjaGVtYXMgb24gTkVUQ09ORiBkZXZp Y2VzIGdvaW5nIHRvIGJlIGEgcmVxdWlyZW1lbnQ/DQpNYXJrOiBOZWVkcyB0byBiZSB3b3JrZWQg b3V0LCBjbGVhcmx5IHNvbWUgZGV2aWNlcyBtYXkgbm90IHdhbnQgdG8gZG8gdGhpcy4NCg0KQW5k eSBCaWVybWFuOiByZWFsbHkgZG9lc24ndCB3YW50IHRvIHJlcXVpcmUgZGV2aWNlcyB0byBzdG9y ZSB0aGVpciBzY2hlbWEuICBXYW50cyB0byBtYWtlIHN1cmUgdGhhdCBpdCdzIG9wdGlvbmFsLiAg DQpNYXJrIGJlbGlldmVzIHRoYXQgdGhlIG9wdGlvbmFsaXR5IGlzIHRoZXJlLg0KDQpROiBEbyB3 ZSBwcmVmZXIgPGdldC1zY2hlbWE+IG92ZXIgYSA8Z2V0Pj8NCk1hcms6IFNvbWUgc2VlbSB0byB3 YW50IDxnZXQtc2NoZW1hPiwgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIgdGhlcmUgaXMgV0cg Y29uc2Vuc3VzOyA8Z2V0LXNjaGVtYT4gZW5zdXJlcyB0aGF0IHBlb3BsZSBkbyBub3QgYWNjaWRl bnRhbGx5IHJldHJpZXZlIHZvbHVtaW5vdXMgc2NoZW1hcy4gSWYgd2UgZ28gd2l0aG91dCA8Z2V0 LXNjaGVtYT4sIG1ha2Ugc3VyZSB0aGUgc2NoZW1hcyBhcmUgZWFzeSB0byBmaWx0ZXIgb3V0Lg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCkltcGxlbWVudGF0aW9uIGRpc2N1c3Npb246DQoNCk1hcnRpbiBCam9ya2x1bmQ6 IEkndmUgaW1wbGVtZW50ZWQgcGFydGlhbCBsb2NraW5nLCBub3QgdGhlIFRMUyBzdHVmZiwgYW5k IHBsYW5uaW5nIHRvIGRvIHRoZSBtb25pdG9yaW5nIGRyYWZ0IHdoZW4gaXQncyBzdGFibGUuDQoN CkJlcnQ6IFdobyB3aWxsIGltcGxlbWVudCBwYXJ0aWFsIGxvY2tpbmc/ICAzIGluZGVwZW5kZW50 IGltcGxlbWVudGF0aW9ucy4gIA0KTW9uaXRvcmluZyBkb2N1bWVudD8gU2FtZSAzLCBwbHVzIG9u ZSBleHRyYSBmcm9tIE5vcnRlbC4gIA0KVExTIGRvY3VtZW50PyAgTm8gaGFuZHMuICANCk1laG1l dDogV2UgZG9uJ3Qga25vdyB3aGF0IEJhZHJhIGlzIGRvaW5nLg0KQmVydDogV2hvIHdpbGwgaW1w bGVtZW50IHRoZSBub3RpZmljYXRpb24gZG9jdW1lbnQ/IDMtNCBpbmRlcGVuZGVudCBpbXBsZW1l bnRhdGlvbnMNCkRhbiBSb21hc2NhbnU6IEFzayBhbGwgdGhlIHF1ZXN0aW9ucyBvbiB0aGUgbWFp bGluZyBsaXN0LCBwbGVhc2UuDQoNCkJlcnQ6IElzIHRoZSBXRyBpbnRlcmVzdGVkIGluIGFuIGlu dGVyb3BlcmFiaWxpdHkgZXZlbnQ/ICBFaXRoZXIgb24gdGhlc2UgZG9jdW1lbnRzIG9yIG9uIHRo ZSBwdWJsaXNoZWQgUkZDcyBvciBib3RoLg0KDQpBamF5IEthY2hyYW5pOiAgSG93IG1hbnkgaW1w bGVtZW50YXRpb25zIG9mIE5FVENPTkYgYXJlIHRoZXJlIGluIGdlbmVyYWwgYW5kIGhvdyB3aWRl bHkgaXMgaXQgZGVwbG95ZWQ/ICANCkJlcnQ6IFRoZXJlIHdlcmUgc29tZXRoaW5nIGxpa2UgNSBp bXBsZW1lbnRhdGlvbnMgd2hlbiB0aGUgbGFzdCBpbnRlcm9wIHdhcyBkb25lLiAgTm8gZmlndXJl cyBhYm91dCBob3cgd2lkZWx5IGl0IGlzIGRlcGxveWVkLg0KDQpCZXJ0OiBXaG8gaXMgaW50ZXJl c3RlZCBpbiBhbiBpbnRlcm9wZXJhYmlsaXR5IGV2ZW50PyBObyBoYW5kcy4NCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpT T0FQIGltcGxlbWVudGF0aW9uIHByZXNlbnRhdGlvbiAoVG9tb3l1a2kgSWlqaW1hKQ0KDQpTbGlk ZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDhtYXIvc2xpZGVzL25ldGNvbmYt NC5wcHQNCg0KQmVydDogVGhpcyBkb2N1bWVudCBpcyBpbiB0aGUgaGFuZHMgb2YgdGhlIElFU0cs IHNvIHdlIGRvbid0IGhhdmUgdG8gZG8gYW55dGhpbmcgZWxzZSB3aXRoIGl0LCBjb3JyZWN0PyAg DQpEYW46IFRoZSBkb2N1bWVudCB3ZW50IHRvIHRoZSBJRVRGIExDLCBoYXMgYmVlbiByZXZpc2Vk LCB3aWxsIG5vdyBnbyB0byB0aGUgSUVTRyByZXZpZXcsIGlmIG1vcmUgZm9sa3Mgd291bGQgcmVh ZCBhbmQgY29tbWVudCB0byBpbXByb3ZlIHRoZSBxdWFsaXR5LCB0aGV5IGFyZSBhbHdheXMgd2Vs Y29tZS4gUGxlYXNlIGZvcndhcmQgdGhlbSB0byBtZSBvciBjb3B5IHRoZSBORVRDT05GIG1haWxs aXN0IGFzIHdlbGwuIFdpbGwgYmUgaW4gYSBmZXcgd2Vla3Mgb24gdGhlIGFnZW5kYSBvZiB0aGUg SUVTRy4NCkJlcnQ6IEFuZCBJIGJlbGlldmUgdGhpcyBkb2N1bWVudCBnb2VzIGZvciBJbmZvcm1h dGlvbmFsLCByaWdodD8NCkRhbjogWWVzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0oYXJvbiBDaGlzaG9sbTogd2UgaGF2ZSB0 byBzdXBwb3J0IHByZS1jb25maWd1cmF0aW9uLiAgQXJlIHdlIG1ha2luZyB0aGF0IGltcG9zc2li bGU/ICANCkJhbGF6czogbm8sIHlvdSBoYXZlIHRvIGRlZmluZSB0aGUgdG9wLWxldmVsIG5vZGUg YW5kIGxvY2sgaXQuDQoNClJhbmR5IFByZXN1aG46IE5vdCBleHBsaWNpdCBpbiB0aGUgZG9jdW1l bnQgdGhhdCBsb2NraW5nIHRoZSBub2RlIGdvdCBhbGwgb2YgaXRzIHN1Ym5vZGVzLiAgSWYgeW91 IGRlbGV0ZSBzb21lIHN1Yi10cmVlIHRoYXQncyBsb2NrZWQsIGNhbiBzb21lb25lIHRoZW4gYWx0 ZXIgaXQ/ICANCkJhbGF6czogTm8sIGFuZCBzaW5jZSBpdCdzIG5vdCBjbGVhciBpbiB0aGUgZHJh ZnQgd2UnbGwgbWFrZSBzdXJlIHdlIHVwZGF0ZSBpdC4NCg0KV3J0IHRvIHdoYXQgdG8gaGF2ZSBh cyBub3JtYXRpdmUgZm9yIG1vZGVsczogQmVydCAtIHNob3VsZG4ndCB0aGUgbm9ybWF0aXZlIG1v ZGVsIGJlIFhTRCBzaW5jZSB0aGF0J3Mgd2hhdCB3ZSBoYXZlIGRvbmUgc28gZmFyPyBCb3RoIGFy ZSBub24tbm9ybWF0aXZlIHRvZGF5LiAgDQpNZWhtZXQ6IG9uZSBvZiB0aGVtIG5lZWRzIHRvIGJl IG5vcm1hdGl2ZS4gIA0KRGFuIFJvbWFzY2FudTogVXNlIHRoZSBYU0Qgc2luY2UgdGhhdCdzIHdo YXQncyB3ZSd2ZSB1c2VkIHNvIGZhciwgcHV0IFlBTkcgaW4gYXMgaW5mb3JtYXRpdmUuIA0KQW5k eSBCaWVybWFuOiBXaGF0IHdvdWxkIGJlIHRoZSBwb2ludCBvZiByZW1vdmluZyB0aGUgWFNEPyAg VGhpcyBpcyBzaW5jZSBCYWxhenMgc3VnZ2VzdGVkIHRoZSBFbmdsaXNoIHRleHQgc2hvdWxkIGJl IG5vcm1hdGl2ZS4gIEFuZHkgb2JqZWN0cyBhbmQgdGhpbmtzIHRoYXQgWFNEIHNob3VsZCBiZSBu b3JtYXRpdmUgc2luY2UgdGhhdCdzIHdoYXQgd2UgaGF2ZS4NCkJhbGF6czogVGhhdCdzIHdoYXQg SSdsbCBkby4NCg0KV2l0aCByZXNwZWN0IHRvIE11bHRpLURhdGFzdG9yZSBsb2NrOg0KRGF2aWQg SGFycmluZ3RvbjogSSBzZW50IHRoZSBxdWVzdGlvbiBiZWNhdXNlIHRoZSBkb2N1bWVudCBzYXlz IGl0IGxvY2tzIG9uZSBvciBtb3JlIGRhdGFzdG9yZXMuICANCkJhbGF6czogSSB3aWxsIHJlbW92 ZSB0aGlzIGZyb20gdGhlIG9wZW4gaXNzdWVzIGFuZCBjaGFuZ2UgaXQgdG8gIm9uZSBvcGVyYXRp b24gbG9ja3Mgb25lIGRhdGFzdG9yZSIuDQoNClNlY3VyaXR5IHNsaWRlOiANCkRhdmlkIFBhcnRh aW46IElzIG1vcmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGV4dCBuZWVkZWQ/IFdobyBzdWdn ZXN0ZWQgaXQgbmVlZHMgdG8gYmUgbW9yZT8NCkJhbGF6czogRGF2aWQgSGFycmluZ3RvbiBhbmQg TWVobWV0IHdlcmUgbWVudGlvbmVkLiAgDQpCZXJ0OiBpc24ndCBwb2ludGluZyBhdCA0NzQxIG9r PyAgDQpEYXZpZCBIYXJyaW5ndG9uOiB0aGVyZSBhcmUgY2FzZXMgdGhhdCBkb24ndCBzZWVtIHRv IGJlIGNvdmVyZWQgc2luY2UgdGhpcyBpcyBub3QgYSBnbG9iYWwgbG9jay4gUGFydGlhbCBsb2Nr aW5nIGlzIGRpZmZlcmVudC4gIA0KQmFsYXpzOiBMb2NrIGV4cHJlc3Npb24gaXMgZXZhbHVhdGVk IHdoZW4gdGhlIGxvY2sgaXMgY3JlYXRlZCBub3Qgd2hlbiBhbiBlZGl0IGV4cHJlc3Npb24gaXMg ZXhlY3V0ZWQuIFdpbGwgYWRkIHNvbWUgdGV4dC4gDQpXZXMgSGFyZGFrZXI6IERvY3VtZW50IGRp ZmZlcmVudGlhdGVzIGJldHdlZW4gYSBnbG9iYWwgbG9jayBhbmQgcGFydGlhbCBsb2NrcyBmb3Ig dGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb25zLiBGb3IgZXhhbXBsZSwgd2hhdCBo YXBwZW5zIGlmIHlvdSBjb3B5IGNhbmRpZGF0ZSB0byBydW5uaW5nIHdoaWxlIGEgcGFydGlhbCBs b2NrIGlzIGhlbGQ/IExvY2tpbmcgZ2l2ZXMgdGhlIGltcHJlc3Npb24gdGhhdCBsb2NraW5nIGdp dmVzIGV4Y2x1c2l2ZSBwb3dlciBhbmQgYWNjZXNzLCBzbyB3ZSBuZWVkIHRvIGRvY3VtZW50IGhv dyBORVRDT05GIG9wZXJhdGlvbnMgYXJlIGFmZmVjdGVkLg0KQmVydDogVGhpcyBzZWVtcyB0byBi ZSBhIGdvb2QgZXhlcmNpc2UuIENvdWxkIHlvdSBwb3N0IHNvbWUgb2YgdGhlc2UgY29uY2VybnMg dG8gdGhlIG1haWxpbmcgbGlzdD8NCldlczogU3VyZS4gIFdlIG5lZWQgYSBtYXRyaXggdGhhdCBj b3ZlcnMgdGhlIHZhcmlvdXMgb3BlcmF0aW9ucyBhbmQgdGhlaXIgaW50ZXJhY3Rpb24uDQoNCkFj Y2VzcyBjb250cm9sIHNsaWRlOiAgDQpCZXJ0OiBJJ20gaGFwcHkgd2l0aCBob3cgeW91IHdvcmRl ZCBpdC4gIEkgdGhpbmsgdGhhdCdzIGdvb2QgZW5vdWdoLiAgSWYgc29tZW9uZSBkaXNhZ3JlZXMg d2l0aCB0aGlzLCBwbGVhc2Ugc2VuZCB0ZXh0LiAgV2UgZG9uJ3Qgd2FudCB0byBibG9jayB0aGlz IGRvY3VtZW50IGJ5IHdhaXRpbmcgZm9yIGFjY2VzcyBjb250cm9sLiAgIA0KRGF2aWQgSGFycmlu Z3RvbjogYXQgb25lIHBvaW50LCB0aGUgZG9jdW1lbnQgc2FpZCB5b3UgaGF2ZSB0byBoYXZlIHJl YWQgcmlnaHRzLiAgDQpCYWxhenM6IEkgYmVsaWV2ZSBpdCBzYXlzICJzb21lIHJpZ2h0cyIuICAN ClNoYXJvbjogaXQgc2hvdWxkIHNheSAieW91IGNhbiBsb2NrIGlmIHlvdSBoYXZlIHN1ZmZpY2ll bnQgcHJpdmlsZWdlcyIuICBXZSBzaG91bGQgbWFrZSBhcyBmZXcgYXNzdW1wdGlvbnMgYXMgcG9z c2libGUgYWJvdXQgYWNjZXNzIGNvbnRyb2wgd2hlbiB3cml0aW5nIHRoaXMgZG9jdW1lbnQuICAN CkFuZHkgQmllcm1hbjoganVzdCBsaWtlIHlvdSBtaWdodCB0YWtlIG91dCBhIGdsb2JhbCBsb2Nr IHRvIGdldCBhIGNvbnNpc3RlbnQgcmVhZCwgeW91IG1pZ2h0IHdhbnQgdG8gZG8gc28gZm9yIHBh cnRpYWwgbG9ja2luZy4NCkFuZHkgQmllcm1hbiBhZ2FpbjogSSBkb24ndCB1bmRlcnN0YW5kIHdo eSB0aGUgc2VjdXJpdHkgaXNzdWVzIGFyZSBkaWZmZXJlbnQgZm9yIHRoaXMgYW5kIGdsb2JhbCBs b2Nrcy4gIA0KQmVydDogV2VzIGhhcyBhbHJlYWR5IGFncmVlZCB0byBzZW5kIHNvbWUgbWFpbCB0 byBkaXNjdXNzIHRoaXMuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLStLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBbnkgb3RoZXIgYnVzaW5lc3M6DQoN CkFjY2VzcyBjb250cm9sOiANCkJlcnQ6IFdobyBpcyBpbnRlcmVzdGVkIHRvIHdvcmsgb24gYWNj ZXNzIGNvbnRyb2w/IEFuZHkgQmllcm1hbiBhbmQgRGF2aWQgSGFycmluZ3RvbiB3b3VsZCBiZSB3 aWxsaW5nIHRvIHB1dCBzb21lIGN5Y2xlcyBpbnRvIHdvcmtpbmcgb24gYWNjZXNzIGNvbnRyb2wu ICANCkJlcnQ6IHdobyB3b3VsZCBjb250cmlidXRlIG90aGVyIHRoYW4gdGhlIGF1dGhvcnM/ICAN ClNoYXJvbjogSSB3b25kZXIgYWJvdXQgdGhlIHVyZ2VuY3kgb2YgdGhpcyB3b3JrLiAgSSdkIGxp a2UgdG8gd2FpdCBhbm90aGVyIGN5Y2xlLiAgDQpBbmR5OiBJJ2QgYmUgaGFwcHkgd2l0aCB0aGF0 LiAgDQpNYXJ0aW4gQmpvcmtsdW5kOiBJIHRoaW5rIGl0IHNob3VsZCBiZSBkZWZlcnJlZCBhcyB3 ZWxsLiAgDQpBbmR5IEJpZXJtYW46IEknZCBiZSBtb3JlIGludGVyZXN0ZWQgaW4gaW1wbGVtZW50 aW5nIHRoZSBub3RpZmljYXRpb24gc3R1ZmYgaWYgdGhlcmUgd2VyZSBpbnRlcmVzdGluZyBpbmZv cm1hdGlvbiBiZWluZyBzZW50Lg0KV2hvIGlzIHdpbGxpbmcgdG8gcmV2aWV3IGRvY3VtZW50cz8g bm8gaGFuZHMNCg0KR2l2ZW4gdGhlIG51bWJlciBvZiB0aGluZ3MgTkVUQ09ORiByZWxhdGVkIHRo aW5ncyBnb2luZyBvbiwgYWNjZXNzIGNvbnRyb2wgZG9lcyBub3Qgc2VlbSB0byBiZSBoaWdoIHBy aW9yaXR5IGF0IHRoZSBtb21lbnQuDQoNCk5vdGlmaWNhdGlvbiBkcmFmdDogKG5vdyBpbiB0aGUg aGFuZHMgb2YgdGhlIElFU0cpICANCldobyB3aWxsIGJlIGltcGxlbWVudGluZyB0aGUgbm90aWZp Y2F0aW9uIGRyYWZ0LiAgNCBpbXBsZW1lbnRhdGlvbnMsIDMgb2YgdGhlbSBmcm9tIE5vcnRlbC4g IA0KDQpOb3RpZmljYXRpb24gY29udGVudDoNClBoaWwgU2hhZmVyOiBhbnkgcGxhbiB0byBzdGFu ZGFyZGl6ZSBjb250ZW50IGZvciB0aGUgbm90aWZpY2F0aW9ucz8gIA0KQmVydDogQW5keSdzIGFs cmVhZHkgc2FpZCBpdCdzIG5vdCBpbnRlcmVzdGluZyB3b3JrIHdpdGhvdXQgaXQsIHNvIEknbSB3 aWxsaW5nIHRvIGVudGVydGFpbiB0aGUgcG9zc2liaWxpdHkuICANClBoaWw6IFdoYXQgd291bGQg YmUgdGhlIGJhc2lzIG9mIHRoYXQgd29yaz8gIFNOTVAgdHJhcHM/ICBTeXNsb2c/ICANClNoYXJv bjogbm9uZSBvZiB0aGUgYWJvdmUuICANClBoaWw6IFNvLCB3b3VsZCB0aGF0IGJlIE5FVENPTkYt c3BlY2lmaWMgbmV3IHdvcms/ICANCkJlcnQ6IHdlIHNob3VsZCBkZWNpZGUgdGhhdC4gIA0KDQpX aWxsIHRoZXJlIGJlIHBlb3BsZSB0byByZXZpZXcgSURzIGZvciBub3RpZmljYXRpb24gY29udGVu dD8gNS02IGhhbmRzIHdlcmUgcmFpc2VkDQpXaG8gd291bGQgYmUgaW50ZXJlc3RlZCB0byByZXZp ZXcgaWYgYSBkb2N1bWVudCB3b3VsZCBjb21lIG91dCBmb3IgU05NUCBvciBTWVNMT0cgbm90aWZp Y2F0aW9ucz8gNC01IGhhbmRzIHdlcmUgcmFpc2VkDQpXaWxsIHRoaXMgYmUgSUVURiBzdGFuZGFy ZHMtdHJhY2sgU1lTTE9HIG9yIGRlcGxveWVkIFNZU0xPRz8gSWRlYWxseSwgdGhpcyB3b3VsZCBj b3ZlciB0aGUgc3RhbmRhcmRzLXRyYWNrIFNZU0xPRyBjb250ZW50Lg0KDQpEYW46IExldCdzIHdy aXRlIHNvbWUgaW50ZXJuZXQgZHJhZnRzLiAgVGhlcmUgc2VlbWVkIHRvIGJlIHN1ZmZpY2llbnQg aW50ZXJlc3QgaW4gY29udGVudCB0aGF0IGlmIHNvbWVvbmUgd291bGQgd3JpdGUgYW4gSUQgKGZv ciBORVRDT05GLXJlbGF0ZWQpLCBwZW9wbGUgd291bGQgbG9vayBhdCBpdC4gIFNhbWUgaXMgdHJ1 ZSBvZiB0aGUgc3lzbG9nLXJlbGF0ZWQgd29yay4gIEJlcnQgc3VnZ2VzdHMgdGhhdCB0aG9zZSBp bnRlcmVzdGVkIHB1Ymxpc2ggZHJhZnRzIGFuZCB0YWtlIGl0IGZyb20gdGhlcmUgZnJvbSB0aGUg bmV4dCBJRVRGLg0KDQotLS0tLS0tLS0tLS0tDQoNCk9wZW4gbWljIHRvcGljIE5FVENPTkYgbW9k ZWxpbmcgcmVxdWlyZW1lbnRzOg0KV2hhdCBETUwgcmVxdWlyZW1lbnRzIGFyZSBpbXBvcnRhbnQg ZnJvbSBhIE5FVENPTkYgcG9pbnQgb2Ygdmlldz8gQXJlIHRoZXJlIGFueSBORVRDT05GIHNwZWNp ZmljIHJlcXVpcmVtZW50cz8NCkRhbiBSb21hc2NhbnU6IHdoYXQgd291bGQgYmUgYSBnb29kIHNj ZW5hcmlvIG9mIHdoYXQgaGFwcGVucyBhdCB0aGUgQ0FOTU9EIEJPRj8NCg0KQmVydDogRG9lc24n dCBzZWVtIGFwcHJvcHJpYXRlIGZvciB0aGUgTkVUQ09ORi4gIElmIHRoZXJlIGFyZSByZXF1aXJl bWVudHMgd2UgdGhpbmsgYXJlIHZlcnkgaW1wb3J0YW50LCBhbmQgd2UgZG9uJ3QgdGhpbmsgd2Ug aGF2ZSBzaW1pbGFyIHZpZXdwb2ludHMsIHRoZW4gZGlzY3Vzc2luZyB0aGVtIGhlcmUgaXMNCmFw cHJvcHJpYXRlLg0KDQpSYW5keSBQcmVzdWhuOiBXZSBoYXZlIGEgbm9uLWFncmVlZCByZXF1aXJl bWVudCBhbmQgd2Ugd2FudCB0byBrbm93IGlmIGl0J3MgZXZlbiBwb3NzaWJsZSBpbiBORVRDT05G LiAgDQpNYXJ0aW4gYWdyZWVkIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlLiAgU3VidHJlZSBmaWx0 ZXJpbmcgZG9lc24ndCB3b3JrIHdpdGggZGVlcCBrZXlzLiANCg0KQW5keSBCaWVybWFuOiB0aGlz IGlzIGEga25vd24gbGltaXRhdGlvbiBvZiBzdWJ0cmVlIGZpbHRlcmluZy4gWFBhdGggdG9vayBj YXJlIG9mIHRoYXQsIGFuZCB3ZSBkaWRuJ3Qgd2FudCB0byByZWludmVudCB0aGF0Lg0KQmVydDog QXJlIHdlIHdpbGxpbmcgdG8gZ2l2ZSB1cCBzdWJ0cmVlIGZpbHRlcmluZyBub3c/DQpBbmR5OiBO bywgdGhhdCdzIG5vdCB3aGF0IHdlJ3JlIHNheWluZy4gIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxk IGhvbGQgdXAgZGF0YSBtb2RlbGluZyBhdCB0aGlzIHBvaW50IGZvciB0aGF0Lg0KUGhpbCBTaGFm ZXI6IG1vdGl2YXRpb24gb2Ygc3VidHJlZSBmaWx0ZXJpbmcgaXMgdG8gYXZvaWQgdGhlIGNvc3Qg b2YgaW1wbGVtZW50aW5nIHhwYXRoIG9uIGEgZGV2aWNlLiAgVGhhdCBjb25zaWRlcmF0aW9uIGlz IHN0aWxsIHRoZXJlLiANCkFuZH0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTkVUQ09ORiBNb25pdG9yaW5nIFNjaGVtYSAoTWFy ayBTY290dCkNCg0KU2xpZGVzOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzA4bWFy L3NsaWRlcy9uZXRjb25mLTUucHB0DQoNClNob3VsZCB3ZSBoYXZlIGEgc3BlY2lhbGl6ZWQgKGlu YmFuZCkgZ2V0LXNjaGVtYSA/DQpTb21lIHNlZW0gdG8gd2FudCBpdCwgbmVlZCB0byBmaWd1cmUg b3V0IHdoZXRoZXIgdGhlcmUgaXMgV0cgY29uc2Vuc3VzLg0KU2hhcm9uIENoaXNob2xtOiBJZiB3 ZSBkZWZpbmUgdGhpcyBhcyBwYXJ0IG9mIHRoZSBkYXRhIG1vZGVsLCB0aGVuIHJldHJpZXZpbmcg dGhlIHdob2xlIGNvbnRlbnRzIG9mIHRoZSBkYXRhc3RvcmUgd2lsbCBhbHNvIGdldCB0aGlzLCB3 aGVyZWFzIGEgc3BlY2lhbGl6ZWQgdmVyYiB3b3VsZCBhbGxvdyB1cyB0byBzY29wZS4NClNvIHRo YXQsIHlvdSByZXRyaWV2ZSB0aGUgc2NoZW1hIGRlZmluaXRpb24gdGhlcmUsIGJ1dCBpdCBkb2Vz IG5vdCBzaG93IHVwIGFzIHBhcnQgb2YgeW91ciBvcGVyYXRpb25hbCBhbmQgY29uZmlndXJhdGlv biBkYXRhLg0KTWFyazogWWVzLCBJIHRob3VnaHQgd2UgZG9uJ3QgbmVlZCB0byBrZWVwIHRoZSBy ZWZlcmVuY2VzIHRvIHRoZSBzY2hlbWEgaW4gdGhlIG5vcm1hbGl6ZWQgbW9uaXRvcmluZyBtb2Rl bC4gVGhlIHNjaGVtYSBtaWdodCBiZWNvbWUgbGFyZ2UsIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHNv bWVvbmUgd2FudHMgdG8gZ2V0IGFsbCBvZiB0aGVtLg0KRGF2aWQgSGFycmluZ3RvbjogIFdoeSBk byB3ZSBoYXZlIHRvIGJlIGFibGUgdG8gZG8gdGhpcyB3aXRoIE5FVENPTkYgcmF0aGVyIHRoYW4g c29tZXRoaW5nIGxpa2UgZnRwPyAgDQpNYXJrOiBPcmlnaW5hbGx5IEkgcHJvcG9zZWQgdGhpcyBi dXQgYSBmZXcgcGVvcGxlIGluIHRoZSBsYXN0IG5lZXRpbmcgYW5kIG9uIHRoZSBtYWlsaXN0IHdo byB3YW50ZWQgdG8gYmUgYWJsZSB0byBkbyBzby4NCkJlcnQ6IERvIHRoZSBwZW9wbGUgaGF2ZSBh biBvcGluaW9uIG9uIHRoYXQ/IEkga25vdyB0aGF0IGEgZmV3IHBlb3BsZSBhc2tlZCB0aGlzLiBU aGUgcXVlc3Rpb24gaXMsIGRvIHdlIGhhdmUgY29uc2Vuc3VzIG9uIHRoaXM/DQpFbWlsZSBTdGVm YW4/IEZyYW5jZSBUZWxlY29tOiBSZWdhcmRpbmcgb3BlcmF0aW9uYWwgbmVlZHMgd2hhdCB3ZSBu ZWVkIGlzIHRoZSBjYXBhYmlsaXR5IG9mIGhvdyB0byBnZXQgdGhlIGxpc3Qgb2YgdGhlIHNjaGVt YXMgb2YgYSBkZXZpY2UgYW5kIGhhdmluZyB0aGUgdmVyc2lvbiBvZiB2YXJpb3VzIHNjaGVtYXMg d2hpY2ggYXJlIGN1cnJlbnRseSBpbXBsZW1lbnRlZCBvbiB0aGUgZGV2aWNlLg0KTWFyazogVGhh dCdzIGN1cnJlbnRseSB0aGVyZSwgeW91IGNhbiBkbyBiYXNpY2FsbHkgYSBnZXQgb24gbW9uaXRv cmluZyBkYXRhIGFuZCByZXR1cm4gYSBsaXN0IGlkZW50aWZpZXJzLCB3aGljaCBhcmUgYmFzaWNh bGx5IHRoZSBzY2hlbWEgbmFtZXMgYW5kIHZlcnNpb24gYW5kIGEgbG9jYXRpb24gKHdoaWNoIGlz IGFuIGZ0cCBvciBhIFVSSSkNClBoaWwgU2hhZmVyOiAgSSB3YW50IHRvIGJlIGFibGUgdG8gcmV0 cmlldmUgaXQgdXNpbmcgTkVUQ09ORi4gV2UncmUgcmVpbnZlbnRpbmcgc3R1ZmYsIGJ1dCBJIHdh bnQgaXQuDQpCZXJ0OiBTbywgeW91IHNlZSB0aGUgYmFkIHNpZGUsIGJ1dCB5b3Ugc3RpbGwgd2Fu dCBpdC4gV2UgbmVlZCB0byBnZXQgY29uc2Vuc3VzIG9uIHRoZSBsaXN0Lg0KTWFyazogV2UnZCBv bmx5IGJlIGFibGUgdG8gcmVzcG9uZCB3aXRoIHBsYWludGV4dCBYTUwsIHdoaWNoIGNhbiBiZSBx dWl0ZSB2ZXJib3NlLiAgV2UgbWF5IHdhbnQgdG8gYmUgYWJsZSB0byBnZXQgaXQgaW4gYW5vdGhl ciBmb3JtYXQsIGkuZSBBU0NJSSB2ZXJzaW9uLg0KDQpXZXMgSGFyZGFrZXI6IE9uZSBvZiB0aGUg Y29tcGxhaW50cyBhYm91dCBTTk1QIGlzIHRoYXQgeW91IGNhbm5vdCBnZXQgdGhlIGluZm9ybWF0 aW9uIGFib3V0IGNhcGFiaWxpdGllcy4gQXMgbWFueSBwZW9wbGUgc2FpZCB0aGlzIGlzIG9uZSBv ZiBtaXNlcmFibGUgZmFpbHVyZXMgd2hlcmUgU01JIGRlYWx0IHdpdGggc3R1ZmYgbGlrZSB0aGlz LCB0aGUgYWdlbnQgY2FwYWJpbGl0aWVzIGFuZCByZWZlcnJhbCBkaWRuJ3Qgd29yay4gSWYgdGhl IGRldmljZSB3b3VsZCBqdXN0IHJldHVybiBpdCdzIGFiaWxpdGllcyB0aGF0IHdvdWxkIGJlIGEg Z29vZCB0aGluZy4gVGhhdCdzIGNlcnRhaW5seSBzb21ldGhpbmcgdG8gZG8uIFRoYXQgYmVpbmcg c2FpZCBpZiB5b3UgZG8gcHVibGlzaCB0aGUgc2NoZW1hIGFuZCB5b3UgZG9uJ3QgZG8gaXQgd2l0 aCBhIHNlcGFyYXRlIGNvbW1hbmQsIG1ha2Ugc3VyZSBpdCBpcyBwdWJsaXNoZWQgaW4gYSBzdGFu ZGFyZGl6ZWQgcGF0dGVybiBvciB0cmVlLCBzbyB5b3UgY2FuIGNvbnNpc3RlbnRseSBibG9jayBv ciBhbGxvdyBhY2Nlc3MgdG8gaXQuIA0KDQpCYWxhenMgTGVuZ3llbDogV2lsbCB5b3UgaW5jbHVk ZSBwYXJ0aWFsIGxvY2tpbmc/ICANCk1hcms6IEkgaGF2ZSB0byBmaWd1cmUgb3V0IGhvdyB0byBp bmNsdWRlIGxvY2tpbmcgZmlyc3QsIEkgaGF2ZSBub3RlZCB0byBpbmNsdWRlIHBhcnRpYWwgbG9j a2luZyBhYnNvbHV0ZWx5LiBJdCBvcGVucyB0aGUgc2FtZSBkaXNjdXNzaW9uIGFzIHdpdGggYWNj ZXNzIGNvbnRyb2wuIFNpbWlsYXJseSwgeW91IG1pZ2h0IHdhbnQgbm90IHRvIHJldHVybiBsb2Nr IGluZm9ybWF0aW9uIGZvciB3aGljaCB5b3UgZG9uJ3QgaGF2ZSB0aGUgdmlzaWJpbGl0eS4gV2Ug aGF2ZSB0byBzb3J0IHRoYXQgb3V0Lg0KDQpCYWxhenMgTGVuZ3llbDogWW91IGhhdmUgYSBzdGF0 ZW1lbnQgdGhhdCB0aGUgY2FwYWJpbGl0eSBzaG91bGQgaW5jbHVkZSBtaW5pbWFsbHkgd2hhdCB3 ZW50IGluICJoYWxsbyBleGNoYW5nZSIuIFdoeSBpcyB0aGlzIGRpZmZlcmVudCBmcm9tIHNjaGVt YSByZXRyaWV2YWwsIHdoeSBub3QgZXhhY3RseSB0aGUgc2FtZSBzZXQ/DQpNYXJrOiBXZSBoYk6IEhvdyBvdXQgb2YgZGF0ZSBpcyBvdXIgeHBhdGggMS4wIG5v dyBhbmQgaW4gdHdvIG9yIHRocmVlIHllYXJzPyAgV2UgdXNlIHRoZSBvdXQgb2YgZGF0ZSB4cGF0 aC4NClBoaWwgU2hhZmVyOiBob3cgbXVjaCByZXN0cmljdGlvbnMgYXJlIHdlIHdpbGxpbmcgdG8g ZG8gaW4gb3JkZXIgdG8gZ2V0IGEgZGF0YSBtb2RlbGluZyBsYW5ndWFnZT8NCkp1ZXJnZW4gU2No b2Vud2FlbGRlcjogaG93IG1hbnkgcGVvcGxlIHVuZGVyc3RhbmQgdGhpcz8gIEFib3V0IDEwIHBl b3BsZSByYWlzZSB0aGVpciBoYW5kcy4gUmVxdWVzdGVkIHRoYXQgdGhpcyBiZSB3cml0dGVuIHVw IGZvciB0aGUgQ0FOTU9EIEJPRi4NClJhbmR5OiBpdCdzIGFscmVhZHkgaW4gdGhlIHJlcXVpcmVt ZW50cyBkcmFmdC4gIA0KDQpBbmR5OiBkZWVwIGtleXMgYXJlIGNvbXBsaWNhdGVkIGFuZCBJIGRv bid0IHRoaW5rIGl0J3Mgd29ydGggaXQgYXQgdGhpcyBwb2ludC4gIA0KDQpSYW5keSBQcmVzdWhu OiBTaW5jZSB3ZSBoYXZlIGltcGxlbWVudG9ycyBoZXJlLCB3aGF0IGhhdmUgcGVvcGxlIGRvbmUg d2l0aCByZXNwZWN0IHRvIGludGVybmF0aW9uYWxpemF0aW9uIGFuZCBsb2NhbGl6YXRpb24gb2Yg ZXJyb3IgbWVzc2FnZXMuICBTb21lIG9mIHRoZXNlIHdlcmUgYWdyZWVkIHJlcXVpcmVtZW50cy4g IA0KUGhpbCBTaGFmZXI6IHdlIGRvbid0IGRvIGFueXRoaW5nIHJpZ2h0IG5vdyBiZWNhdXNlIHRo ZSBjb3N0IGlzIHByb2hpYml0aXZlLg0KQmFsYXpzOiBJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyB2 ZXJ5IGV4cGVuc2l2ZSB0byBnZXQgaXQgcmlnaHQuDQoNCg0KQW5keSBCaWVybWFuOiBJZiB0aGVy ZSB3ZXJlIGxpYnJhcmllcyB0aGF0IGFsbG93ZWQgbWUgdG8gZG8gdGhpcywgSSdkIHByb2JhYmx5 IHN1cHBvcnQgaXQsIGJ1dCBJIGRvbid0IGhhdmUgYW55dGhpbmcgcmlnaHQgbm93Lg0KDQpCZXJ0 OiBNYXliZSBjdXJyZW50IGN1c3RvbWVycyBhcmUgb2sgd2l0aCBFbmdsaXNoLCBidXQgcGVyaGFw cyBvdGhlciBjdXN0b21lcnMgd29uJ3QgYmUgYXMgd2UgZ3Jvdy4gIA0KUGhpbCBTaGFmZXI6IFRo ZXJlIGFyZSBtdWx0aXBsZSBwcm9ibGVtcyBpbnZvbHZlZC4gIFRvIGdvIGFsbCB0aGUgd2F5LCB0 aGUgZXhwZW5zZSBpcyBzaW1wbHkgdG9vIGhpZ2guDQpCYWxhenMgTGVuZ3llbDogSSBhZ3JlZSB3 aXRoIFBoaWwuDQpCZXJ0OiAgZG9lcyB0aGlzIGhlbHA/DQpSYW5keTogIERvbid0IGtub3csIGJ1 dCBpdCdzIG1vcmUgaW5mb3JtYXRpb24uDQpSYW5keTogIm5vdGlmaWNhdGlvbiBnZXQiIHdhcyBh bHNvIG5vdCBhbiBhZ3JlZWQgcmVxdWlyZW1lbnQuICANCg0KQmVydDogaG93IGRvZXMgdGhpcyBm aXQgaW50byBkYXRhIG1vZGVsaW5nPyBXaHkgaXMgdGhpcyBhIGRhdGEgbW9kZWxpbmcgbGFuZ3Vh Z2UgcmVxdWlyZW1lbnQ/DQpTaGFyb246IFRoZSBjb25jZXB0IGlzIHRoYXQgYSBjaHVuayBvZiBk ZWZpbml0aW9uIHRoYXQgY291bGQgYmUgdXNlZCB0byByZXRyaWV2ZSBpbmZvcm1hdGlvbiBjb3Vs ZCBiZSB1c2VkIGFzIHRoZSBwYXlsb2FkIG9mIGEgbm90aWZpY2F0aW9uIG9yIHZpY2UgdmVyc2Eu DQpUaGUgcXVlc3Rpb24gaXMgd2hldGhlciAoY29uZmlnKSBkYXRhIGNhbiBiZSB1c2VkIGZvciBu b3RpZmljYXRpb25zIGFuZCB2aWNlIHZlcnNhLg0KDQpSYW5keTogRG8gcGVvcGxlIHNlZSBhIHZh bHVlIG9mIHRoYXQgbGV2ZWwgb2YgcmV1c2U/IFByb2JhYmx5IGFueSBvZiB0aGUgc29sdXRpb25z IGlzIGdvaW5nIHRvIGJlIGFibGUgdG8gc3VwcG9ydCB0aGlzLCBzbyBpdCBkb2Vzbid0IHJlYWxs eSBoZWxwIHVzIHRvIGRldGVybWluZSB3aGljaCBvbmUgd2Ugc2hvdWxkIHVzZS4NCkRvZXMgdGhp cyBpbXBhY3QgdGhlIGNob2ljZSBvZiB0aGUgbGFuZ3VhZ2U/DQoNCkJlcnQ6IFJldXNlIGlzIGdv b2QuDQoNClBoaWwgU2hhZmVyOiBJIHRob3VnaHQgSSB1bmRlcnN0b29kLCBidXQgSSdtIGdldHRp bmcgbXVsdGlwbGUgYW5zd2Vycy4gVGhpcyByZXF1aXJlbWVudCBkb2VzIG5vdCBoZWxwIHRvIGRl Y2lkZSBiZXR3ZWVuIGxhbmd1YWdlcy4gTWFydGluIGRvZXMgbm90IHRoaW5rIGl0IG1lYW5zIHRo YXQgeW91IHJldXNlIGEgY29tcGxleCB0eXBlLiBIZSB0aGlua3MgaXQgbWVhbnMgdGhhdCB0aGlz IHBhcnQgb2YgdGhlIHRyZWUgY2FuIGJlIHRhZ2dlZCB0aGF0IGl0IG1heSBiZSBwYXJ0IG9mIGEg bm90aWZpY2F0aW9uLiBJdCBpcyBhYm91dCB0aGUgdXNlIG9mIChjb25maWcpIGluc3RhbmNlIGRh dGEgaW4gbm90aWZpY2F0aW9ucy4gDQpCZXJ0OiBEb2VzIHRoYXQgbWVhbiB0aGF0IHdoZW4geW91 IGRlZmluZSBkYXRhLCB5b3Ugc2F5IHRoYXQgaXQgd2lsbCBiZSBhdmFpbGFibGUgZm9yIHJlYWQs IGZvciBub3RpZmljYXRpb25zLCBldGM/ICANClNoYXJvbjogeWVzLiAgDQpBbmR5OiB0aGlzIGRv ZXNuJ3Qgc2VlbSB0aGF0IGhhcmQgdG8gbWUuICBMaWtlIFNOTVAsIHdoZW4geW91IGRlY2xhcmUg YSBub3RpZmljYXRpb24gbWFjcm8sIGl0J3MgYnVpbGQgaW50byB0aGUgZGVmaW5pdGlvbiwgeW91 IHNlbmQgYSBjb3B5LCBpdCdzIHVuZGVyc3Rvb2QgaXQncyBub3QgdGhlIHJlYWwgb25lLCBpdCdz IGEgY29weS4gV2h5IHdvdWxkIHdlIG5lZWQgdGhlIHNhbWUgdGhpbmcsIGl0J3MgYSBtZWNoYW5p c20gaW4geW91ciBsYW5ndWFnZSwgd2hpY2ggc2F5cywgSSdtIHNlbmRpbmcgYSBjb3B5IG9mIHRo YXQuIEl0IGRvZXNuJ3QgaGF2ZSB0byBiZSB0aGUgbmFtZSBvZiB0aGUgbGVhZi4gDQpCZXJ0OiBQ aGlsIHlvdSBoYXZlIHRoZSBmaW5hbCB3b3JkLg0KUGhpbDogSG93IGNvb2wuIE15IHF1ZXN0aW9u IGlzIHdoYXQgaWYgdGhlIHRoaW5nIHlvdSB0YWcgaXMgYmVpbmcgcGFydCBvZiB0aGUgbm90aWZp Y2F0aW9uIGJlbG9uZ3MgdW5kZXIgdGhlIGhpZXJhcmNoeSBhbmQgd2l0aG91dCB0aGUgaGllcmFy Y2h5IGl0IGRvZXMgbm90IG1ha2Ugc2Vuc2UuIElmIEkgc2F5LCBoZXJlIGlzIG15IE1UVSBhbmQg aWYgSSB0aHJvdyBteSBNVFUgaW50byB0aGUgbm90aWZpY2F0aW9uIHlvdSBoYXZlIG5vIGlkZWEg d2hhdCBpdCBtZWFucy4NCg0KVGhlIGNoYWlyczogQWxscmlnaHQsIHRoYW5rIHlvdSBhbGwsIHdl IGFyZSBhdCB0aGUgZW5kIG9yIG91ciBzZXNzaW9uIGFuZCBJIGd1ZXNzIG1hbnkgb2YgeW91IHdl IHdpbGwgc2VlIGF0IHRoZSBuZXh0IElFVEYNClBMRUFTRSBkbyBicmluZyB1cCB0aGUgdmFyaW91 cyBpdGVtcyBvbiB0aGUgbWFpbGluZyBsaXN0IChhcyBkaXNjdXNzZWQvYWdyZWVkIGFib3ZlKS4N ClBMRUFTRSBkbyBzdWJtaXQgSW50ZXJuZXQtRHJhZnRzIGZvciB3b3JrIHRoYXQgeW91IGZlZWwg bmVlZHMgdG8gYmUgY29uc2lkZXJlZC4= ------_=_NextPart_001_01C8901F.8D33B0C4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8901F.8D33B0C4-- XZl IGFuIGV4YW1wbGUgd2hlcmUgd2UgZG9uJ3Qgd2FudCB0byBwdXQgZXZlcnl0aGluZyBpbiB0aGUg Y2FwYWJpbGl0aWVzIGV4Y2hhbmdlIGJlY2F1c2UgYmFzZWQgb24gdGhlIGNvbmZpZ3VyYXRpb24g b2YgdGhlIGJveCBkdXJpbmcgdGhlIHNlc3Npb24gdGhlIHNjaGVtYSB0aGF0IGlzIHJlbGV2YW50 IGNhbiBjaGFuZ2UuIEUuZy4gaWYgSSBlbmFibGUgYSBwYXJ0aWN1bGFyIHR5cGUgb2YgaW50ZXJm YWNlIEkgd2lsbCBub3cgYWR2ZXJ0aXNlIGl0J3Mgc2NoZW1hIGFzIGJlaW5nIHN1cHBvcnRlZCBv biB0aGUgYm94Lg0KDQpROiBEbyB5b3UgcmVwb3J0IHN0YXRlIGFib3V0IHBhcnRpYWwgbG9ja3M/ DQpNYXJrOiBZZXMuDQoNClE6IFdoYXQgaXMgdGhlIHNldCBvZiBtaW5pbWFsbHkgYW5ub3VuY2Vk IGNhcGFiaWxpdGllcz8NCk1hcms6IEl0IG1pZ2h0IGJlIHVzZWZ1bC4uLg0KDQpROiBMb3RzIG9m IGRldGFpbGVkIHF1ZXN0aW9ucyBvdXQgdGhlcmUgc2luY2UgdGhlIGRvY3VtZW50IGlzIHNvbWV0 aW1lcyB2YWd1ZT8NCk1hcms6IFdlIGhhdmUgdG8gd29yayB0aHJvdWdoIHRoZW0uDQoNClE6IENh biB0aGUgZmlsZTogVVJOIG5vdCBiZSB1c2VkIHRvIHJlcG9ydCBhIGxvY2FsbHkgc3RvcmVkIHNj aGVtYT8NCk1hcms6IE1pZ2h0IGJlIHdvcmthYmxlLg0KDQpROiBJcyBzY2hlbWEgYWR2ZXJ0aXNl bWVudCBtYW5kYXRvcnk/IElzIHRoZSBzdG9yYWdlIG9mIHNjaGVtYXMgb24gTkVUQ09ORiBkZXZp Y2VzIGdvaW5nIHRvIGJlIGEgcmVxdWlyZW1lbnQ/DQpNYXJrOiBOZWVkcyB0byBiZSB3b3JrZWQg b3V0LCBjbGVhcmx5IHNvbWUgZGV2aWNlcyBtYXkgbm90IHdhbnQgdG8gZG8gdGhpcy4NCg0KQW5k eSBCaWVybWFuOiByZWFsbHkgZG9lc24ndCB3YW50IHRvIHJlcXVpcmUgZGV2aWNlcyB0byBzdG9y ZSB0aGVpciBzY2hlbWEuICBXYW50cyB0byBtYWtlIHN1cmUgdGhhdCBpdCdzIG9wdGlvbmFsLiAg DQpNYXJrIGJlbGlldmVzIHRoYXQgdGhlIG9wdGlvbmFsaXR5IGlzIHRoZXJlLg0KDQpROiBEbyB3 ZSBwcmVmZXIgPGdldC1zY2hlbWE+IG92ZXIgYSA8Z2V0Pj8NCk1hcms6IFNvbWUgc2VlbSB0byB3 YW50IDxnZXQtc2NoZW1hPiwgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIgdGhlcmUgaXMgV0cg Y29uc2Vuc3VzOyA8Z2V0LXNjaGVtYT4gZW5zdXJlcyB0aGF0IHBlb3BsZSBkbyBub3QgYWNjaWRl bnRhbGx5IHJldHJpZXZlIHZvbHVtaW5vdXMgc2NoZW1hcy4gSWYgd2UgZ28gd2l0aG91dCA8Z2V0 LXNjaGVtYT4sIG1ha2Ugc3VyZSB0aGUgc2NoZW1hcyBhcmUgZWFzeSB0byBmaWx0ZXIgb3V0Lg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCkltcGxlbWVudGF0aW9uIGRpc2N1c3Npb246DQoNCk1hcnRpbiBCam9ya2x1bmQ6 IEkndmUgaW1wbGVtZW50ZWQgcGFydGlhbCBsb2NraW5nLCBub3QgdGhlIFRMUyBzdHVmZiwgYW5k IHBsYW5uaW5nIHRvIGRvIHRoZSBtb25pdG9yaW5nIGRyYWZ0IHdoZW4gaXQncyBzdGFibGUuDQoN CkJlcnQ6IFdobyB3aWxsIGltcGxlbWVudCBwYXJ0aWFsIGxvY2tpbmc/ICAzIGluZGVwZW5kZW50 IGltcGxlbWVudGF0aW9ucy4gIA0KTW9uaXRvcmluZyBkb2N1bWVudD8gU2FtZSAzLCBwbHVzIG9u ZSBleHRyYSBmcm9tIE5vcnRlbC4gIA0KVExTIGRvY3VtZW50PyAgTm8gaGFuZHMuICANCk1laG1l dDogV2UgZG9uJ3Qga25vdyB3aGF0IEJhZHJhIGlzIGRvaW5nLg0KQmVydDogV2hvIHdpbGwgaW1w bGVtZW50IHRoZSBub3RpZmljYXRpb24gZG9jdW1lbnQ/IDMtNCBpbmRlcGVuZGVudCBpbXBsZW1l bnRhdGlvbnMNCkRhbiBSb21hc2NhbnU6IEFzayBhbGwgdGhlIHF1ZXN0aW9ucyBvbiB0aGUgbWFp bGluZyBsaXN0LCBwbGVhc2UuDQoNCkJlcnQ6IElzIHRoZSBXRyBpbnRlcmVzdGVkIGluIGFuIGlu dGVyb3BlcmFiaWxpdHkgZXZlbnQ/ICBFaXRoZXIgb24gdGhlc2UgZG9jdW1lbnRzIG9yIG9uIHRo ZSBwdWJsaXNoZWQgUkZDcyBvciBib3RoLg0KDQpBamF5IEthY2hyYW5pOiAgSG93IG1hbnkgaW1w bGVtZW50YXRpb25zIG9mIE5FVENPTkYgYXJlIHRoZXJlIGluIGdlbmVyYWwgYW5kIGhvdyB3aWRl bHkgaXMgaXQgZGVwbG95ZWQ/ICANCkJlcnQ6IFRoZXJlIHdlcmUgc29tZXRoaW5nIGxpa2UgNSBp bXBsZW1lbnRhdGlvbnMgd2hlbiB0aGUgbGFzdCBpbnRlcm9wIHdhcyBkb25lLiAgTm8gZmlndXJl cyBhYm91dCBob3cgd2lkZWx5IGl0IGlzIGRlcGxveWVkLg0KDQpCZXJ0OiBXaG8gaXMgaW50ZXJl c3RlZCBpbiBhbiBpbnRlcm9wZXJhYmlsaXR5IGV2ZW50PyBObyBoYW5kcy4NCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpT T0FQIGltcGxlbWVudGF0aW9uIHByZXNlbnRhdGlvbiAoVG9tb3l1a2kgSWlqaW1hKQ0KDQpTbGlk ZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDhtYXIvc2xpZGVzL25ldGNvbmYt NC5wcHQNCg0KQmVydDogVGhpcyBkb2N1bWVudCBpcyBpbiB0aGUgaGFuZHMgb2YgdGhlIElFU0cs IHNvIHdlIGRvbid0IGhhdmUgdG8gZG8gYW55dGhpbmcgZWxzZSB3aXRoIGl0LCBjb3JyZWN0PyAg DQpEYW46IFRoZSBkb2N1bWVudCB3ZW50IHRvIHRoZSBJRVRGIExDLCBoYXMgYmVlbiByZXZpc2Vk LCB3aWxsIG5vdyBnbyB0byB0aGUgSUVTRyByZXZpZXcsIGlmIG1vcmUgZm9sa3Mgd291bGQgcmVh ZCBhbmQgY29tbWVudCB0byBpbXByb3ZlIHRoZSBxdWFsaXR5LCB0aGV5IGFyZSBhbHdheXMgd2Vs Y29tZS4gUGxlYXNlIGZvcndhcmQgdGhlbSB0byBtZSBvciBjb3B5IHRoZSBORVRDT05GIG1haWxs aXN0IGFzIHdlbGwuIFdpbGwgYmUgaW4gYSBmZXcgd2Vla3Mgb24gdGhlIGFnZW5kYSBvZiB0aGUg SUVTRy4NCkJlcnQ6IEFuZCBJIGJlbGlldmUgdGhpcyBkb2N1bWVudCBnb2VzIGZvciBJbmZvcm1h dGlvbmFsLCByaWdodD8NCkRhbjogWWVzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBbnkgb3RoZXIgYnVzaW5lc3M6DQoN CkFjY2VzcyBjb250cm9sOiANCkJlcnQ6IFdobyBpcyBpbnRlcmVzdGVkIHRvIHdvcmsgb24gYWNj ZXNzIGNvbnRyb2w/IEFuZHkgQmllcm1hbiBhbmQgRGF2aWQgSGFycmluZ3RvbiB3b3VsZCBiZSB3 aWxsaW5nIHRvIHB1dCBzb21lIGN5Y2xlcyBpbnRvIHdvcmtpbmcgb24gYWNjZXNzIGNvbnRyb2wu ICANCkJlcnQ6IHdobyB3b3VsZCBjb250cmlidXRlIG90aGVyIHRoYW4gdGhlIGF1dGhvcnM/ICAN ClNoYXJvbjogSSB3b25kZXIgYWJvdXQgdGhlIHVyZ2VuY3kgb2YgdGhpcyB3b3JrLiAgSSdkIGxp a2UgdG8gd2FpdCBhbm90aGVyIGN5Y2xlLiAgDQpBbmR5OiBJJ2QgYmUgaGFwcHkgd2l0aCB0aGF0 LiAgDQpNYXJ0aW4gQmpvcmtsdW5kOiBJIHRoaW5rIGl0IHNob3VsZCBiZSBkZWZlcnJlZCBhcyB3 ZWxsLiAgDQpBbmR5IEJpZXJtYW46IEknZCBiZSBtb3JlIGludGVyZXN0ZWQgaW4gaW1wbGVtZW50 aW5nIHRoZSBub3RpZmljYXRpb24gc3R1ZmYgaWYgdGhlcmUgd2VyZSBpbnRlcmVzdGluZyBpbmZv cm1hdGlvbiBiZWluZyBzZW50Lg0KV2hvIGlzIHdpbGxpbmcgdG8gcmV2aWV3IGRvY3VtZW50cz8g bm8gaGFuZHMNCg0KR2l2ZW4gdGhlIG51bWJlciBvZiB0aGluZ3MgTkVUQ09ORiByZWxhdGVkIHRo aW5ncyBnb2luZyBvbiwgYWNjZXNzIGNvbnRyb2wgZG9lcyBub3Qgc2VlbSB0byBiZSBoaWdoIHBy aW9yaXR5IGF0IHRoZSBtb21lbnQuDQoNCk5vdGlmaWNhdGlvbiBkcmFmdDogKG5vdyBpbiB0aGUg aGFuZHMgb2YgdGhlIElFU0cpICANCldobyB3aWxsIGJlIGltcGxlbWVudGluZyB0aGUgbm90aWZp Y2F0aW9uIGRyYWZ0LiAgNCBpbXBsZW1lbnRhdGlvbnMsIDMgb2YgdGhlbSBmcm9tIE5vcnRlbC4g IA0KDQpOb3RpZmljYXRpb24gY29udGVudDoNClBoaWwgU2hhZmVyOiBhbnkgcGxhbiB0byBzdGFu ZGFyZGl6ZSBjb250ZW50IGZvciB0aGUgbm90aWZpY2F0aW9ucz8gIA0KQmVydDogQW5keSdzIGFs cmVhZHkgc2FpZCBpdCdzIG5vdCBpbnRlcmVzdGluZyB3b3JrIHdpdGhvdXQgaXQsIHNvIEknbSB3 aWxsaW5nIHRvIGVudGVydGFpbiB0aGUgcG9zc2liaWxpdHkuICANClBoaWw6IFdoYXQgd291bGQg YmUgdGhlIGJhc2lzIG9mIHRoYXQgd29yaz8gIFNOTVAgdHJhcHM/ICBTeXNsb2c/ICANClNoYXJv bjogbm9uZSBvZiB0aGUgYWJvdmUuICANClBoaWw6IFNvLCB3b3VsZCB0aGF0IGJlIE5FVENPTkYt c3BlY2lmaWMgbmV3IHdvcms/ICANCkJlcnQ6IHdlIHNob3VsZCBkZWNpZGUgdGhhdC4gIA0KDQpX aWxsIHRoZXJlIGJlIHBlb3BsZSB0byByZXZpZXcgSURzIGZvciBub3RpZmljYXRpb24gY29udGVu dD8gNS02IGhhbmRzIHdlcmUgcmFpc2VkDQpXaG8gd291bGQgYmUgaW50ZXJlc3RlZCB0byByZXZp ZXcgaWYgYSBkb2N1bWVudCB3b3VsZCBjb21lIG91dCBmb3IgU05NUCBvciBTWVNMT0cgbm90aWZp Y2F0aW9ucz8gNC01IGhhbmRzIHdlcmUgcmFpc2VkDQpXaWxsIHRoaXMgYmUgSUVURiBzdGFuZGFy ZHMtdHJhY2sgU1lTTE9HIG9yIGRlcGxveWVkIFNZU0xPRz8gSWRlYWxseSwgdGhpcyB3b3VsZCBj b3ZlciB0aGUgc3RhbmRhcmRzLXRyYWNrIFNZU0xPRyBjb250ZW50Lg0KDQpEYW46IExldCdzIHdy aXRlIHNvbWUgaW50ZXJuZXQgZHJhZnRzLiAgVGhlcmUgc2VlbWVkIHRvIGJlIHN1ZmZpY2llbnQg aW50ZXJlc3QgaW4gY29udGVudCB0aGF0IGlmIHNvbWVvbmUgd291bGQgd3JpdGUgYW4gSUQgKGZv ciBORVRDT05GLXJlbGF0ZWQpLCBwZW9wbGUgd291bGQgbG9vayBhdCBpdC4gIFNhbWUgaXMgdHJ1 ZSBvZiB0aGUgc3lzbG9nLXJlbGF0ZWQgd29yay4gIEJlcnQgc3VnZ2VzdHMgdGhhdCB0aG9zZSBp bnRlcmVzdGVkIHB1Ymxpc2ggZHJhZnRzIGFuZCB0YWtlIGl0IGZyb20gdGhlcmUgZnJvbSB0aGUg bmV4dCBJRVRGLg0KDQotLS0tLS0tLS0tLS0tDQoNCk9wZW4gbWljIHRvcGljIE5FVENPTkYgbW9k ZWxpbmcgcmVxdWlyZW1lbnRzOg0KV2hhdCBETUwgcmVxdWlyZW1lbnRzIGFyZSBpbXBvcnRhbnQg ZnJvbSBhIE5FVENPTkYgcG9pbnQgb2Ygdmlldz8gQXJlIHRoZXJlIGFueSBORVRDT05GIHNwZWNp ZmljIHJlcXVpcmVtZW50cz8NCkRhbiBSb21hc2NhbnU6IHdoYXQgd291bGQgYmUgYSBnb29kIHNj ZW5hcmlvIG9mIHdoYXQgaGFwcGVucyBhdCB0aGUgQ0FOTU9EIEJPRj8NCg0KQmVydDogRG9lc24n dCBzZWVtIGFwcHJvcHJpYXRlIGZvciB0aGUgTkVUQ09ORi4gIElmIHRoZXJlIGFyZSByZXF1aXJl bWVudHMgd2UgdGhpbmsgYXJlIHZlcnkgaW1wb3J0YW50LCBhbmQgd2UgZG9uJ3QgdGhpbmsgd2Ug aGF2ZSBzaW1pbGFyIHZpZXdwb2ludHMsIHRoZW4gZGlzY3Vzc2luZyB0aGVtIGhlcmUgaXMNCmFw cHJvcHJpYXRlLg0KDQpSYW5keSBQcmVzdWhuOiBXZSBoYXZlIGEgbm9uLWFncmVlZCByZXF1aXJl bWVudCBhbmQgd2Ugd2FudCB0byBrbm93IGlmIGl0J3MgZXZlbiBwb3NzaWJsZSBpbiBORVRDT05G LiAgDQpNYXJ0aW4gYWdyZWVkIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlLiAgU3VidHJlZSBmaWx0 ZXJpbmcgZG9lc24ndCB3b3JrIHdpdGggZGVlcCBrZXlzLiANCg0KQW5keSBCaWVybWFuOiB0aGlz IGlzIGEga25vd24gbGltaXRhdGlvbiBvZiBzdWJ0cmVlIGZpbHRlcmluZy4gWFBhdGggdG9vayBj YXJlIG9mIHRoYXQsIGFuZCB3ZSBkaWRuJ3Qgd2FudCB0byByZWludmVudCB0aGF0Lg0KQmVydDog QXJlIHdlIHdpbGxpbmcgdG8gZ2l2ZSB1cCBzdWJ0cmVlIGZpbHRlcmluZyBub3c/DQpBbmR5OiBO bywgdGhhdCdzIG5vdCB3aGF0IHdlJ3JlIHNheWluZy4gIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxk IGhvbGQgdXAgZGF0YSBtb2RlbGluZyBhdCB0aGlzIHBvaW50IGZvciB0aGF0Lg0KUGhpbCBTaGFm ZXI6IG1vdGl2YXRpb24gb2Ygc3VidHJlZSBmaWx0ZXJpbmcgaXMgdG8gYXZvaWQgdGhlIGNvc3Qg b2YgaW1wbGVtZW50aW5nIHhwYXRoIG9uIGEgZGV2aWNlLiAgVGhhdCBjb25zaWRlcmF0aW9uIGlz IHN0aWxsIHRoZXJlLiANCkFuZHk6IEhvdyBvdXQgb2YgZGF0ZSBpcyBvdXIgeHBhdGggMS4wIG5v dyBhbmQgaW4gdHdvIG9yIHRocmVlIHllYXJzPyAgV2UgdXNlIHRoZSBvdXQgb2YgZGF0ZSB4cGF0 aC4NClBoaWwgU2hhZmVyOiBob3cgbXVjaCByZXN0cmljdGlvbnMgYXJlIHdlIHdpbGxpbmcgdG8g ZG8gaW4gb3JkZXIgdG8gZ2V0IGEgZGF0YSBtb2RlbGluZyBsYW5ndWFnZT8NCkp1ZXJnZW4gU2No b2Vud2FlbGRlcjogaG93IG1hbnkgcGVvcGxlIHVuZGVyc3RhbmQgdGhpcz8gIEFib3V0IDEwIHBl b3BsZSByYWlzZSB0aGVpciBoYW5kcy4gUmVxdWVzdGVkIHRoYXQgdGhpcyBiZSB3cml0dGVuIHVw IGZvciB0aGUgQ0FOTU9EIEJPRi4NClJhbmR5OiBpdCdzIGFscmVhZHkgaW4gdGhlIHJlcXVpcmVt ZW50cyBkcmFmdC4gIA0KDQpBbmR5OiBkZWVwIGtleXMgYXJlIGNvbXBsaWNhdGVkIGFuZCBJIGRv bid0IHRoaW5rIGl0J3Mgd29ydGggaXQgYXQgdGhpcyBwb2ludC4gIA0KDQpSYW5keSBQcmVzdWhu OiBTaW5jZSB3ZSBoYXZlIGltcGxlbWVudG9ycyBoZXJlLCB3aGF0IGhhdmUgcGVvcGxlIGRvbmUg d2l0aCByZXNwZWN0IHRvIGludGVybmF0aW9uYWxpemF0aW9uIGFuZCBsb2NhbGl6YXRpb24gb2Yg ZXJyb3IgbWVzc2FnZXMuICBTb21lIG9mIHRoZXNlIHdlcmUgYWdyZWVkIHJlcXVpcmVtZW50cy4g IA0KUGhpbCBTaGFmZXI6IHdlIGRvbid0IGRvIGFueXRoaW5nIHJpZ2h0IG5vdyBiZWNhdXNlIHRo ZSBjb3N0IGlzIHByb2hpYml0aXZlLg0KQmFsYXpzOiBJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyB2 ZXJ5IGV4cGVuc2l2ZSB0byBnZXQgaXQgcmlnaHQuDQoNCg0KQW5keSBCaWVybWFuOiBJZiB0aGVy ZSB3ZXJlIGxpYnJhcmllcyB0aGF0IGFsbG93ZWQgbWUgdG8gZG8gdGhpcywgSSdkIHByb2JhYmx5 IHN1cHBvcnQgaXQsIGJ1dCBJIGRvbid0IGhhdmUgYW55dGhpbmcgcmlnaHQgbm93Lg0KDQpCZXJ0 OiBNYXliZSBjdXJyZW50IGN1c3RvbWVycyBhcmUgb2sgd2l0aCBFbmdsaXNoLCBidXQgcGVyaGFw cyBvdGhlciBjdXN0b21lcnMgd29uJ3QgYmUgYXMgd2UgZ3Jvdy4gIA0KUGhpbCBTaGFmZXI6IFRo ZXJlIGFyZSBtdWx0aXBsZSBwcm9ibGVtcyBpbnZvbHZlZC4gIFRvIGdvIGFsbCB0aGUgd2F5LCB0 aGUgZXhwZW5zZSBpcyBzaW1wbHkgdG9vIGhpZ2guDQpCYWxhenMgTGVuZ3llbDogSSBhZ3JlZSB3 aXRoIFBoaWwuDQpCZXJ0OiAgZG9lcyB0aGlzIGhlbHA/DQpSYW5keTogIERvbid0IGtub3csIGJ1 dCBpdCdzIG1vcmUgaW5mb3JtYXRpb24uDQpSYW5keTogIm5vdGlmaWNhdGlvbiBnZXQiIHdhcyBh bHNvIG5vdCBhbiBhZ3JlZWQgcmVxdWlyZW1lbnQuICANCg0KQmVydDogaG93IGRvZXMgdGhpcyBm aXQgaW50byBkYXRhIG1vZGVsaW5nPyBXaHkgaXMgdGhpcyBhIGRhdGEgbW9kZWxpbmcgbGFuZ3Vh Z2UgcmVxdWlyZW1lbnQ/DQpTaGFyb246IFRoZSBjb25jZXB0IGlzIHRoYXQgYSBjaHVuayBvZiBk ZWZpbml0aW9uIHRoYXQgY291bGQgYmUgdXNlZCB0byByZXRyaWV2ZSBpbmZvcm1hdGlvbiBjb3Vs ZCBiZSB1c2VkIGFzIHRoZSBwYXlsb2FkIG9mIGEgbm90aWZpY2F0aW9uIG9yIHZpY2UgdmVyc2Eu DQpUaGUgcXVlc3Rpb24gaXMgd2hldGhlciAoY29uZmlnKSBkYXRhIGNhbiBiZSB1c2VkIGZvciBu b3RpZmljYXRpb25zIGFuZCB2aWNlIHZlcnNhLg0KDQpSYW5keTogRG8gcGVvcGxlIHNlZSBhIHZh bHVlIG9mIHRoYXQgbGV2ZWwgb2YgcmV1c2U/IFByb2JhYmx5IGFueSBvZiB0aGUgc29sdXRpb25z IGlzIGdvaW5nIHRvIGJlIGFibGUgdG8gc3VwcG9ydCB0aGlzLCBzbyBpdCBkb2Vzbid0IHJlYWxs eSBoZWxwIHVzIHRvIGRldGVybWluZSB3aGljaCBvbmUgd2Ugc2hvdWxkIHVzZS4NCkRvZXMgdGhp cyBpbXBhY3QgdGhlIGNob2ljZSBvZiB0aGUgbGFuZ3VhZ2U/DQoNCkJlcnQ6IFJldXNlIGlzIGdv b2QuDQoNClBoaWwgU2hhZmVyOiBJIHRob3VnaHQgSSB1bmRlcnN0b29kLCBidXQgSSdtIGdldHRp bmcgbXVsdGlwbGUgYW5zd2Vycy4gVGhpcyByZXF1aXJlbWVudCBkb2VzIG5vdCBoZWxwIHRvIGRl Y2lkZSBiZXR3ZWVuIGxhbmd1YWdlcy4gTWFydGluIGRvZXMgbm90IHRoaW5rIGl0IG1lYW5zIHRo YXQgeW91IHJldXNlIGEgY29tcGxleCB0eXBlLiBIZSB0aGlua3MgaXQgbWVhbnMgdGhhdCB0aGlz IHBhcnQgb2YgdGhlIHRyZWUgY2FuIGJlIHRhZ2dlZCB0aGF0IGl0IG1heSBiZSBwYXJ0IG9mIGEg bm90aWZpY2F0aW9uLiBJdCBpcyBhYm91dCB0aGUgdXNlIG9mIChjb25maWcpIGluc3RhbmNlIGRh dGEgaW4gbm90aWZpY2F0aW9ucy4gDQpCZXJ0OiBEb2VzIHRoYXQgbWVhbiB0aGF0IHdoZW4geW91 IGRlZmluZSBkYXRhLCB5b3Ugc2F5IHRoYXQgaXQgd2lsbCBiZSBhdmFpbGFibGUgZm9yIHJlYWQs IGZvciBub3RpZmljYXRpb25zLCBldGM/ICANClNoYXJvbjogeWVzLiAgDQpBbmR5OiB0aGlzIGRv ZXNuJ3Qgc2VlbSB0aGF0IGhhcmQgdG8gbWUuICBMaWtlIFNOTVAsIHdoZW4geW91IGRlY2xhcmUg YSBub3RpZmljYXRpb24gbWFjcm8sIGl0J3MgYnVpbGQgaW50byB0aGUgZGVmaW5pdGlvbiwgeW91 IHNlbmQgYSBjb3B5LCBpdCdzIHVuZGVyc3Rvb2QgaXQncyBub3QgdGhlIHJlYWwgb25lLCBpdCdz IGEgY29weS4gV2h5IHdvdWxkIHdlIG5lZWQgdGhlIHNhbWUgdGhpbmcsIGl0J3MgYSBtZWNoYW5p c20gaW4geW91ciBsYW5ndWFnZSwgd2hpY2ggc2F5cywgSSdtIHNlbmRpbmcgYSBjb3B5IG9mIHRo YXQuIEl0IGRvZXNuJ3QgaGF2ZSB0byBiZSB0aGUgbmFtZSBvZiB0aGUgbGVhZi4gDQpCZXJ0OiBQ aGlsIHlvdSBoYXZlIHRoZSBmaW5hbCB3b3JkLg0KUGhpbDogSG93IGNvb2wuIE15IHF1ZXN0aW9u IGlzIHdoYXQgaWYgdGhlIHRoaW5nIHlvdSB0YWcgaXMgYmVpbmcgcGFydCBvZiB0aGUgbm90aWZp Y2F0aW9uIGJlbG9uZ3MgdW5kZXIgdGhlIGhpZXJhcmNoeSBhbmQgd2l0aG91dCB0aGUgaGllcmFy Y2h5IGl0IGRvZXMgbm90IG1ha2Ugc2Vuc2UuIElmIEkgc2F5LCBoZXJlIGlzIG15IE1UVSBhbmQg aWYgSSB0aHJvdyBteSBNVFUgaW50byB0aGUgbm90aWZpY2F0aW9uIHlvdSBoYXZlIG5vIGlkZWEg d2hhdCBpdCBtZWFucy4NCg0KVGhlIGNoYWlyczogQWxscmlnaHQsIHRoYW5rIHlvdSBhbGwsIHdl IGFyZSBhdCB0aGUgZW5kIG9yIG91ciBzZXNzaW9uIGFuZCBJIGd1ZXNzIG1hbnkgb2YgeW91IHdl IHdpbGwgc2VlIGF0IHRoZSBuZXh0IElFVEYNClBMRUFTRSBkbyBicmluZyB1cCB0aGUgdmFyaW91 cyBpdGVtcyBvbiB0aGUgbWFpbGluZyBsaXN0IChhcyBkaXNjdXNzZWQvYWdyZWVkIGFib3ZlKS4N ClBMRUFTRSBkbyBzdWJtaXQgSW50ZXJuZXQtRHJhZnRzIGZvciB3b3JrIHRoYXQgeW91IGZlZWwg bmVlZHMgdG8gYmUgY29uc2lkZXJlZC4= ------_=_NextPart_001_01C8901F.8D33B0C4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8901F.8D33B0C4-- From netconf-bounces@ietf.org Thu Mar 27 09:11:57 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D0428C8D4; Thu, 27 Mar 2008 09:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.842 X-Spam-Level: X-Spam-Status: No, score=-100.842 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsX+X2Umex9a; Thu, 27 Mar 2008 09:11:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C253A7006; Thu, 27 Mar 2008 09:11:54 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603EC3A6862 for ; Thu, 27 Mar 2008 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbjMPlRopccy for ; Thu, 27 Mar 2008 09:11:52 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 2424D3A7009 for ; Thu, 27 Mar 2008 09:11:07 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id 6BFo1Z00G17UAYkAA0SY00; Thu, 27 Mar 2008 16:08:25 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id 6G8h1Z00H4HwxpC8Z00000; Thu, 27 Mar 2008 16:08:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=I3HcnYfjpJQA:10 a=urxC-ER5H6ahJfc7zTcA:9 a=S-UNI624iAIx70pgCGWv3b5qspIA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=B8yD3sjkmFG54WmTDnYA:9 a=cHXnGBhu8PtwCy53hocA:7 a=N0E2tlmB_DpCR00PPsLW7HK_uBwA:4 a=AfD3MYMu9mQA:10 From: "David B Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: Date: Thu, 27 Mar 2008 12:08:41 -0400 Message-ID: <087b01c89024$d40b4570$6c02a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciQH4xZE3IGYmtEStu5MRTiDeeJswABSvgA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Subject: Re: [Netconf] Netconf session at IETF 71 - Preliminary minutes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0178071889==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0178071889== Content-Type: multipart/alternative; boundary="----=_NextPart_000_087C_01C89003.4CF9A570" This is a multi-part message in MIME format. ------=_NextPart_000_087C_01C89003.4CF9A570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, one correction: "Ideally, this would cover the standards-track SYSLOG content." s/content/protocol/ dbh _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 27, 2008 11:31 AM To: netconf@ietf.org Subject: [Netconf] Netconf session at IETF 71 - Preliminary minutes Hi All, attached are the draft minutes we have merged so far from the notes of the minute takers (many thanks again to David P. and Juergen for taking notes!! :). <> Please send us your change requests or corrections by 10th of April. I'll put it also the meeting materials site as the preliminary version. Thank you. Bert & Mehmet ------=_NextPart_000_087C_01C89003.4CF9A570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Netconf session at IETF 71 - Preliminary = minutes
Hi,
 
one correction:
"Ideally, this would cover the = standards-track=20 SYSLOG content."
s/content/protocol/
 
dbh

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Thursday, March 27, 2008 11:31 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] Netconf session at IETF = 71 -=20 Preliminary minutes


Hi All,

attached are the draft minutes we = have merged so=20 far
from the notes of the = minute takers=20 (many thanks again
to David = P. and=20 Juergen for taking notes!! :).

<<Netconf_IETF=20 71_Draft_minutes.txt>>

Please send us your change requests = or=20 corrections
by 10th of April. = I'll put it=20 also the meeting materials
site as the=20 preliminary version.

Thank you.

Bert = &=20 Mehmet =

------=_NextPart_000_087C_01C89003.4CF9A570-- --===============0178071889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0178071889==-- From netconf-bounces@ietf.org Thu Mar 27 09:11:57 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D0428C8D4; Thu, 27 Mar 2008 09:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.842 X-Spam-Level: X-Spam-Status: No, score=-100.842 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsX+X2Umex9a; Thu, 27 Mar 2008 09:11:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C253A7006; Thu, 27 Mar 2008 09:11:54 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603EC3A6862 for ; Thu, 27 Mar 2008 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbjMPlRopccy for ; Thu, 27 Mar 2008 09:11:52 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 2424D3A7009 for ; Thu, 27 Mar 2008 09:11:07 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id 6BFo1Z00G17UAYkAA0SY00; Thu, 27 Mar 2008 16:08:25 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id 6G8h1Z00H4HwxpC8Z00000; Thu, 27 Mar 2008 16:08:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=I3HcnYfjpJQA:10 a=urxC-ER5H6ahJfc7zTcA:9 a=S-UNI624iAIx70pgCGWv3b5qspIA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=B8yD3sjkmFG54WmTDnYA:9 a=cHXnGBhu8PtwCy53hocA:7 a=N0E2tlmB_DpCR00PPsLW7HK_uBwA:4 a=AfD3MYMu9mQA:10 From: "David B Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: Date: Thu, 27 Mar 2008 12:08:41 -0400 Message-ID: <087b01c89024$d40b4570$6c02a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciQH4xZE3IGYmtEStu5MRTiDeeJswABSvgA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Subject: Re: [Netconf] Netconf session at IETF 71 - Preliminary minutes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0178071889==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0178071889== Content-Type: multipart/alternative; boundary="----=_NextPart_000_087C_01C89003.4CF9A570" This is a multi-part message in MIME format. ------=_NextPart_000_087C_01C89003.4CF9A570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, one correction: "Ideally, this would cover the standards-track SYSLOG content." s/content/protocol/ dbh _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 27, 2008 11:31 AM To: netconf@ietf.org Subject: [Netconf] Netconf session at IETF 71 - Preliminary minutes Hi All, attached are the draft minutes we have merged so far from the notes of the minute takers (many thanks again to David P. and Juergen for taking notes!! :). <> Please send us your change requests or corrections by 10th of April. I'll put it also the meeting materials site as the preliminary version. Thank you. Bert & Mehmet ------=_NextPart_000_087C_01C89003.4CF9A570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Netconf session at IETF 71 - Preliminary = minutes
Hi,
 
one correction:
"Ideally, this would cover the = standards-track=20 SYSLOG content."
s/content/protocol/
 
dbh

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Thursday, March 27, 2008 11:31 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] Netconf session at IETF = 71 -=20 Preliminary minutes


Hi All,

attached are the draft minutes we = have merged so=20 far
from the notes of the = minute takers=20 (many thanks again
to David = P. and=20 Juergen for taking notes!! :).

<<Netconf_IETF=20 71_Draft_minutes.txt>>

Please send us your change requests = or=20 corrections
by 10th of April. = I'll put it=20 also the meeting materials
site as the=20 preliminary version.

Thank you.

Bert = &=20 Mehmet =

------=_NextPart_000_087C_01C89003.4CF9A570-- --===============0178071889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0178071889==-- From netconf-bounces@ietf.org Thu Mar 27 16:21:08 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3C03A6A86; Thu, 27 Mar 2008 16:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.198 X-Spam-Level: X-Spam-Status: No, score=-98.198 tagged_above=-999 required=5 tests=[AWL=-0.360, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHq3B+1ii6Bp; Thu, 27 Mar 2008 16:21:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760333A6A35; Thu, 27 Mar 2008 16:21:07 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86213A69FC for ; Thu, 27 Mar 2008 16:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kQ3IOlzi5bH for ; Thu, 27 Mar 2008 16:21:05 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 49B7C3A692D for ; Thu, 27 Mar 2008 16:21:03 -0700 (PDT) Received: (qmail 83123 invoked from network); 27 Mar 2008 23:18:42 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 27 Mar 2008 23:18:42 -0000 From: "Bert Wijnen - IETF" To: "Sharon Chisholm" , "Hector Trevino \(htrevino\)" Date: Fri, 28 Mar 2008 00:18:42 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: Netconf Subject: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-notification X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org OK, so I propose this is one thing to be fixed by the authors (together with the otehr things that need fixing). Bert Wijnen -----Oorspronkelijk bericht----- Van: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Verzonden: donderdag 27 maart 2008 20:55 Aan: Sharon Chisholm; Pasi Eronen; iesg@ietf.org CC: htrevino@cisco.com; draft-ietf-netconf-notification@tools.ietf.org; netconf-chairs@tools.ietf.org; bertietf@bwijnen.net Onderwerp: RE: DISCUSS and COMMENT: draft-ietf-netconf-notification From the argumentation that Pasi made in the telechat, it looks like the practice of referring schemas with URLs is not used in RFCs, as it leads to potentially high traffic on servers. Specifically Pasi wrote the following: ------------------ To give more background: a very long time ago, W3C decided to use http URIs for HTML DTD/schema names; today, they're seeing "up to 130 million requests per day, with periods of sustained bandwidth usage of 350Mbps": http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic In the case of netconf-notification, there's doesn't seem to From netconf-bounces@ietf.org Thu Mar 27 16:21:08 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3C03A6A86; Thu, 27 Mar 2008 16:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.198 X-Spam-Level: X-Spam-Status: No, score=-98.198 tagged_above=-999 required=5 tests=[AWL=-0.360, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHq3B+1ii6Bp; Thu, 27 Mar 2008 16:21:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760333A6A35; Thu, 27 Mar 2008 16:21:07 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86213A69FC for ; Thu, 27 Mar 2008 16:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kQ3IOlzi5bH for ; Thu, 27 Mar 2008 16:21:05 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 49B7C3A692D for ; Thu, 27 Mar 2008 16:21:03 -0700 (PDT) Received: (qmail 83123 invoked from network); 27 Mar 2008 23:18:42 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 27 Mar 2008 23:18:42 -0000 From: "Bert Wijnen - IETF" To: "Sharon Chisholm" , "Hector Trevino \(htrevino\)" Date: Fri, 28 Mar 2008 00:18:42 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: Netconf Subject: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-notification X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org OK, so I propose this is one thing to be fixed by the authors (together with the otehr things that need fixing). Bert Wijnen -----Oorspronkelijk bericht----- Van: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Verzonden: donderdag 27 maart 2008 20:55 Aan: Sharon Chisholm; Pasi Eronen; iesg@ietf.org CC: htrevino@cisco.com; draft-ietf-netconf-notification@tools.ietf.org; netconf-chairs@tools.ietf.org; bertietf@bwijnen.net Onderwerp: RE: DISCUSS and COMMENT: draft-ietf-netconf-notification From the argumentation that Pasi made in the telechat, it looks like the practice of referring schemas with URLs is not used in RFCs, as it leads to potentially high traffic on servers. Specifically Pasi wrote the following: ------------------ To give more background: a very long time ago, W3C decided to use http URIs for HTML DTD/schema names; today, they're seeing "up to 130 million requests per day, with periods of sustained bandwidth usage of 350Mbps": http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic In the case of netconf-notification, there's doesn't seem to be any advantage in using http URIs (compared to the "urn:ietf:params:xml:..." URNs that all current RFCs use): no valid NETCONF implementation will ever need to download the schema from IANA. Therefore, I don't think we should take a risk by trying something totally new here. -------------------- > -----Original Message----- > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On > Behalf Of Sharon Chisholm > Sent: Thursday, March 27, 2008 9:45 PM > To: Pasi Eronen; iesg@ietf.org > Cc: htrevino@cisco.com; > draft-ietf-netconf-notification@tools.ietf.org; > netconf-chairs@tools.ietf.org; bertietf@bwijnen.net > Subject: RE: DISCUSS and COMMENT: draft-ietf-netconf-notification > > Hi > > I assume you are referring to the following: > > > schemaLocation= > > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > > > Is there a specific issue with this? The link works. > > For expressing the restrictions on stopTime/startTime in the > XSD, can you propose specific syntax? > > Sharon > > -----Original Message----- > From: Pasi Eronen [mailto:pasi.eronen@nokia.com] > Sent: Thursday, March 27, 2008 9:48 AM > To: iesg@ietf.org > Cc: netconf-chairs@tools.ietf.org; > draft-ietf-netconf-notification@tools.ietf.org; Chisholm, > Sharon (CAR:ZZ00); htrevino@cisco.com; bertietf@bwijnen.net > Subject: DISCUSS and COMMENT: draft-ietf-netconf-notification > > Discuss: > The schema "import" statements have HTTP URLs pointing to > www.iana.org. > I don't think any IETF XML schema has done this before? > > Comment: > The restrictions "[replayLogCreationTime] MUST be present if > replay is supported" could be expressed in XML schema, > instead of just documentation. Ditto for "[stopTime] must be > used with startTime". > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf be any advantage in using http URIs (compared to the "urn:ietf:params:xml:..." URNs that all current RFCs use): no valid NETCONF implementation will ever need to download the schema from IANA. Therefore, I don't think we should take a risk by trying something totally new here. -------------------- > -----Original Message----- > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On > Behalf Of Sharon Chisholm > Sent: Thursday, March 27, 2008 9:45 PM > To: Pasi Eronen; iesg@ietf.org > Cc: htrevino@cisco.com; > draft-ietf-netconf-notification@tools.ietf.org; > netconf-chairs@tools.ietf.org; bertietf@bwijnen.net > Subject: RE: DISCUSS and COMMENT: draft-ietf-netconf-notification > > Hi > > I assume you are referring to the following: > > > schemaLocation= > > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > > > Is there a specific issue with this? The link works. > > For expressing the restrictions on stopTime/startTime in the > XSD, can you propose specific syntax? > > Sharon > > -----Original Message----- > From: Pasi Eronen [mailto:pasi.eronen@nokia.com] > Sent: Thursday, March 27, 2008 9:48 AM > To: iesg@ietf.org > Cc: netconf-chairs@tools.ietf.org; > draft-ietf-netconf-notification@tools.ietf.org; Chisholm, > Sharon (CAR:ZZ00); htrevino@cisco.com; bertietf@bwijnen.net > Subject: DISCUSS and COMMENT: draft-ietf-netconf-notification > > Discuss: > The schema "import" statements have HTTP URLs pointing to > www.iana.org. > I don't think any IETF XML schema has done this before? > > Comment: > The restrictions "[replayLogCreationTime] MUST be present if > replay is supported" could be expressed in XML schema, > instead of just documentation. Ditto for "[stopTime] must be > used with startTime". > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Mar 28 06:19:20 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1861928C2C0; Fri, 28 Mar 2008 06:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.388 X-Spam-Level: X-Spam-Status: No, score=-99.388 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pFCZU9trgMC; Fri, 28 Mar 2008 06:19:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D994A28C234; Fri, 28 Mar 2008 06:19:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB173A6C71 for ; Fri, 28 Mar 2008 06:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MR5cWPKPsdS for ; Fri, 28 Mar 2008 06:19:09 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 0C9EA3A6C34 for ; Fri, 28 Mar 2008 06:18:57 -0700 (PDT) Received: (qmail 66396 invoked from network); 28 Mar 2008 13:18:56 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Mar 2008 13:18:56 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Fri, 28 Mar 2008 14:18:57 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] Plan to resolve IESG DISCUSS comments on the netconf-notifications draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WG members, I am speaking as document shepherd for the notifications draft. Clearly we got too many and a few not so-easy to answer comments at the last minute (i.e. over the last few hours) and too short before the actual IESG conf call. I believe most (if not all have been forwarded with some initial reactions to this list already, if not, that will happen soon). The authors, our AD and I have tried to answer a few of those comments with an initial response. A final response will need more checking, and probably we need to update the doc with yet one more revision. In any event, we need (the authors/editors) to send answers (and proposed text changes) to the WG list and give people time to review/check and object if they think we're making serious changes. So this is all gonna cost some time. But.... If at all possible, I would like to get this done and completed quickly. We have some contraints: - I (document shepherd) will be on vacation from 3-10 april (inclusive). - April 17th there is an informal "iesg telechat to clear DISCUSSes". So that is an ideal chance to get our document approved. - April 18 our AD goes on vFrom netconf-bounces@ietf.org Fri Mar 28 06:19:20 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1861928C2C0; Fri, 28 Mar 2008 06:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.388 X-Spam-Level: X-Spam-Status: No, score=-99.388 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pFCZU9trgMC; Fri, 28 Mar 2008 06:19:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D994A28C234; Fri, 28 Mar 2008 06:19:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB173A6C71 for ; Fri, 28 Mar 2008 06:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MR5cWPKPsdS for ; Fri, 28 Mar 2008 06:19:09 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 0C9EA3A6C34 for ; Fri, 28 Mar 2008 06:18:57 -0700 (PDT) Received: (qmail 66396 invoked from network); 28 Mar 2008 13:18:56 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Mar 2008 13:18:56 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Fri, 28 Mar 2008 14:18:57 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] Plan to resolve IESG DISCUSS comments on the netconf-notifications draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WG members, I am speaking as document shepherd for the notifications draft. Clearly we got too many and a few not so-easy to answer comments at the last minute (i.e. over the last few hours) and too short before the actual IESG conf call. I believe most (if not all have been forwarded with some initial reactions to this list already, if not, that will happen soon). The authors, our AD and I have tried to answer a few of those comments with an initial response. A final response will need more checking, and probably we need to update the doc with yet one more revision. In any event, we need (the authors/editors) to send answers (and proposed text changes) to the WG list and give people time to review/check and object if they think we're making serious changes. So this is all gonna cost some time. But.... If at all possible, I would like to get this done and completed quickly. We have some contraints: - I (document shepherd) will be on vacation from 3-10 april (inclusive). - April 17th there is an informal "iesg telechat to clear DISCUSSes". So that is an ideal chance to get our document approved. - April 18 our AD goes on vacation, so that is an other reason to try and get thing finalized BEFORE that date. I think this means that we need to submit a new (agreed upon. i.e. have (at least rough) consensus on) revision at the latest on April 15th, so that IESG members can check the final text before their April 17th telechat. So here is a schedule/plan of action(s) that the authors (and AD) have agreed to: - Between now and april 2nd (inclusive): Editors/authors (Sharon/Hector) send responses to the commenters (copying document shepherd at least, but feel free to copy the WG list as well) and interact with them to try and get the comments addressed. Aither by: . getting a response from the commenter that he/she accepts the explanation . getting a response from the commenter that our proposed text change will address the comment. - No later than april 3rd: Editors/authors make sure that any final new text that needs to go in a revised document gets posted to the mailing list. - Between April 3rd and 9th (inclusive) the WG has a chance to comment on any proposed text changes or to object if they see an issue. - April 11-12th: Bert (as document shepherd, but with Memhmet if there are WG consensus questions) checks all the postings and makes sure everything is addressed. - April 13-15th Editors/authors make sure that final agreed upon text changes are merged into a new revision of the draft and post such a new revision to the internet drafts repository. - april 15-17th Bert/Dan alert each individual AD with a DISCUSS about the new draft and try to make them change their DISCUSS to a NO-OBJECTION. So you are all prepared to expect discussion on this in the coming weeks. Pls pay immediate attention to any postings on this topic, because at the end, there will be very little time left to re-review the complete new draft. But we should have agreed on text beforehand. If anyone has a serious problem with this, Or if anyone finds (during the course of this process) that changes are being made that absolutely need more review and/or discussion time, then PLEASE DO SPEAK UP. Otherwise we will go ahead accoring to the above plan. Bert Wijnen Document Shepherd _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf acation, so that is an other reason to try and get thing finalized BEFORE that date. I think this means that we need to submit a new (agreed upon. i.e. have (at least rough) consensus on) revision at the latest on April 15th, so that IESG members can check the final text before their April 17th telechat. So here is a schedule/plan of action(s) that the authors (and AD) have agreed to: - Between now and april 2nd (inclusive): Editors/authors (Sharon/Hector) send responses to the commenters (copying document shepherd at least, but feel free to copy the WG list as well) and interact with them to try and get the comments addressed. Aither by: . getting a response from the commenter that he/she accepts the explanation . getting a response from the commenter that our proposed text change will address the comment. - No later than april 3rd: Editors/authors make sure that any final new text that needs to go in a revised document gets posted to the mailing list. - Between April 3rd and 9th (inclusive) the WG has a chance to comment on any proposed text changes or to object if they see an issue. - April 11-12th: Bert (as document shepherd, but with Memhmet if there are WG consensus questions) checks all the postings and makes sure everything is addressed. - April 13-15th Editors/authors make sure that final agreed upon text changes are merged into a new revision of the draft and post such a new revision to the internet drafts repository. - april 15-17th Bert/Dan alert each individual AD with a DISCUSS about the new draft and try to make them change their DISCUSS to a NO-OBJECTION. So you are all prepared to expect discussion on this in the coming weeks. Pls pay immediate attention to any postings on this topic, because at the end, there will be very little time left to re-review the complete new draft. But we should have agreed on text beforehand. If anyone has a serious problem with this, Or if anyone finds (during the course of this process) that changes are being made that absolutely need more review and/or discussion time, then PLEASE DO SPEAK UP. Otherwise we will go ahead accoring to the above plan. Bert Wijnen Document Shepherd _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Mar 28 06:23:02 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757443A6C60; Fri, 28 Mar 2008 06:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.701 X-Spam-Level: X-Spam-Status: No, score=-99.701 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqKEOwdSeq0X; Fri, 28 Mar 2008 06:23:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64D13A691C; Fri, 28 Mar 2008 06:23:01 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1173A691C for ; Fri, 28 Mar 2008 06:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnUZ-X3Fe0Pf for ; Fri, 28 Mar 2008 06:23:00 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id F29413A67E6 for ; Fri, 28 Mar 2008 06:22:59 -0700 (PDT) Received: (qmail 70147 invoked from network); 28 Mar 2008 13:22:54 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Mar 2008 13:22:54 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Fri, 28 Mar 2008 14:22:55 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] Pointer to the current IESG DISCUSS materials for the netconf-notifications draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org FYI and review. https://datatracker.ietf.org/idtracker/ballot/2699/ Bert Wijnen _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Mar 28 06:23:02 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757443A6C60; Fri, 28 Mar 2008 06:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.701 X-Spam-Level: X-Spam-Status: No, score=-99.701 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqKEOwdSeq0X; Fri, 28 Mar 2008 06:23:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64D13A691C; Fri, 28 Mar 2008 06:23:01 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1173A691C for ; Fri, 28 Mar 2008 06:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnUZ-X3Fe0Pf for ; Fri, 28 Mar 2008 06:23:00 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id F29413A67E6 for ; Fri, 28 Mar 2008 06:22:59 -0700 (PDT) Received: (qmail 70147 invoked from network); 28 Mar 2008 13:22:54 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Mar 2008 13:22:54 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Fri, 28 Mar 2008 14:22:55 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] Pointer to the current IESG DISCUSS materials for the netconf-notifications draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org FYI and review. https://datatracker.ietf.org/idtracker/ballot/2699/ Bert Wijnen _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf