From j.schoenwaelder@jacobs-university.de Tue Jul 3 05:53:08 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD33421F853B for ; Tue, 3 Jul 2012 05:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvdPsZ+FFtX5 for ; Tue, 3 Jul 2012 05:53:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DA64E21F8425 for ; Tue, 3 Jul 2012 05:53:04 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 326F920BC1; Tue, 3 Jul 2012 14:53:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Gvj1QixRFmtN; Tue, 3 Jul 2012 14:53:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC1B420933; Tue, 3 Jul 2012 14:53:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A1B0320424DB; Tue, 3 Jul 2012 14:53:10 +0200 (CEST) Date: Tue, 3 Jul 2012 14:53:10 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20120703125308.GB1361@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] chunked framing and constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 12:53:09 -0000 Hi, one thing we noted during our implementation exercise on devices where memory is a very limited resource is that chunked framing is pretty cool for sending data since this allows to send larger NETCONF messages without having to have a large buffer to hold it. On the receiving side, things are not as nice since the sender chunks messages to its own liking. There is no way to tell the sender "please do not send chunks larger than my buffer" since the assumption is that there is always enough memory. For really small devices, we found that it is crucial that sizes of the IP packet, TCP segment, TLS record and NETCONF chunk are all well aligned so that a single buffer can be used to process a packet all the way up to the server logic. This is just for your information in case we ever get serious about NETCONF on constrained devices... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Tue Jul 3 07:01:31 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1245111E80D5; Tue, 3 Jul 2012 07:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY-1mY0KkjjC; Tue, 3 Jul 2012 07:01:30 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DF0BC11E807F; Tue, 3 Jul 2012 07:01:29 -0700 (PDT) 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 q63E1Y7q022810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jul 2012 16:01:34 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q63E1XIk031477; Tue, 3 Jul 2012 16:01:33 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jul 2012 16:01:33 +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 Date: Tue, 3 Jul 2012 16:01:33 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403FCE65B@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120703115832.GA669@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Modeling NETCONF Event Notifications Thread-Index: Ac1ZEzEsLpP9ABFTTBe+4FVLmJNAKAAEL4YA References: <4FF2C373.5040806@mg-soft.com> <20120703115832.GA669@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Jernej Tuljak" , X-OriginalArrivalTime: 03 Jul 2012 14:01:33.0824 (UTC) FILETIME=[5AA79800:01CD5924] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1383 X-purgate-ID: 151667::1341324094-00003CDD-8717DADA/0-0/0-0 Cc: NETMOD Working Group Subject: Re: [Netconf] [netmod] Modeling NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 14:01:31 -0000 True. Is there any volunteer willing to yangify RFC 5277? Mehmet=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of ext > Juergen Schoenwaelder > Sent: Tuesday, July 03, 2012 1:59 PM > To: Jernej Tuljak > Cc: NETMOD Working Group > Subject: Re: [netmod] Modeling NETCONF Event Notifications >=20 > On Tue, Jul 03, 2012 at 12:03:31PM +0200, Jernej Tuljak wrote: >=20 > > I have questions regarding NETCONF Notifications and YANG. Which > > YANG module is the standard module that models RFC5277 > > notifications? I've got nc-notifications@2008-07-14 > > and notifications@2008-07-14 > > over here, but it's quite evident > > that they are part of yuma's netconfd. Are these what I'm looking > > for? >=20 > RFC 5277 predates the 'yangification' of the NETCONF specification and > there likely is a need to update/redo RFC 5277 at some point in time. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Tue Jul 3 07:28:21 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF0D21F874C for ; Tue, 3 Jul 2012 07:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfj3IUeDekEx for ; Tue, 3 Jul 2012 07:28:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C29BE21F8747 for ; Tue, 3 Jul 2012 07:28:19 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 595F220BDB; Tue, 3 Jul 2012 16:28:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TXThZIFT8Ee3; Tue, 3 Jul 2012 16:28:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04CEB20BC1; Tue, 3 Jul 2012 16:28:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 40E132042878; Tue, 3 Jul 2012 16:28:26 +0200 (CEST) Date: Tue, 3 Jul 2012 16:28:25 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20120703142825.GC1361@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Jernej Tuljak , netconf@ietf.org References: <4FF2C373.5040806@mg-soft.com> <20120703115832.GA669@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403FCE65B@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403FCE65B@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] [netmod] Modeling NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 14:28:21 -0000 Hi, another option (in theory) would be to merge RFC 5277 into a future version of NETCONF as a capability. Anyway, this seems to belong to NETCONF space, so I remove NETMOD from the CC list. /js On Tue, Jul 03, 2012 at 04:01:33PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > True. Is there any volunteer willing to yangify RFC 5277? > > Mehmet > > > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of ext > > Juergen Schoenwaelder > > Sent: Tuesday, July 03, 2012 1:59 PM > > To: Jernej Tuljak > > Cc: NETMOD Working Group > > Subject: Re: [netmod] Modeling NETCONF Event Notifications > > > > On Tue, Jul 03, 2012 at 12:03:31PM +0200, Jernej Tuljak wrote: > > > > > I have questions regarding NETCONF Notifications and YANG. Which > > > YANG module is the standard module that models RFC5277 > > > notifications? I've got nc-notifications@2008-07-14 > > > and notifications@2008-07-14 > > > over here, but it's quite evident > > > that they are part of yuma's netconfd. Are these what I'm looking > > > for? > > > > RFC 5277 predates the 'yangification' of the NETCONF specification and > > there likely is a need to update/redo RFC 5277 at some point in time. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Tue Jul 3 07:35:31 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FE511E80BC for ; Tue, 3 Jul 2012 07:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM+NRwh8NFoF for ; Tue, 3 Jul 2012 07:35:30 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 36BF811E807F for ; Tue, 3 Jul 2012 07:35:30 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q63EZZwQ001634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jul 2012 16:35:35 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q63EZYT6013269; Tue, 3 Jul 2012 16:35:34 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jul 2012 16:35:04 +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 Date: Tue, 3 Jul 2012 16:35:03 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403FCE696@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120703142825.GC1361@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Modeling NETCONF Event Notifications Thread-Index: Ac1ZKB0+gxImQuhHREaJrFRMGhK5MQAAGUrw References: <4FF2C373.5040806@mg-soft.com> <20120703115832.GA669@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403FCE65B@DEMUEXC006.nsn-intra.net> <20120703142825.GC1361@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 03 Jul 2012 14:35:04.0348 (UTC) FILETIME=[090535C0:01CD5929] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2521 X-purgate-ID: 151667::1341326135-00003CDD-705355C0/0-0/0-0 Cc: netconf@ietf.org Subject: Re: [Netconf] [netmod] Modeling NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 14:35:31 -0000 However, aligning RFC 5277 with RFC 6241 can be done pretty fast. As I understand people don't want to open a new construction ground with RFC 6241, or? Mehmet=20 > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, July 03, 2012 4:28 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: Jernej Tuljak; netconf@ietf.org > Subject: Re: [netmod] Modeling NETCONF Event Notifications >=20 > Hi, >=20 > another option (in theory) would be to merge RFC 5277 into a future > version of NETCONF as a capability. Anyway, this seems to belong to > NETCONF space, so I remove NETMOD from the CC list. >=20 > /js >=20 > On Tue, Jul 03, 2012 at 04:01:33PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > True. Is there any volunteer willing to yangify RFC 5277? > > > > Mehmet > > > > > > > -----Original Message----- > > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > > Behalf Of ext > > > Juergen Schoenwaelder > > > Sent: Tuesday, July 03, 2012 1:59 PM > > > To: Jernej Tuljak > > > Cc: NETMOD Working Group > > > Subject: Re: [netmod] Modeling NETCONF Event Notifications > > > > > > On Tue, Jul 03, 2012 at 12:03:31PM +0200, Jernej Tuljak wrote: > > > > > > > I have questions regarding NETCONF Notifications and YANG. Which > > > > YANG module is the standard module that models RFC5277 > > > > notifications? I've got nc-notifications@2008-07-14 > > > > and notifications@2008-07-14 > > > > over here, but it's quite evident > > > > that they are part of yuma's netconfd. Are these what I'm looking > > > > for? > > > > > > RFC 5277 predates the 'yangification' of the NETCONF specification and > > > there likely is a need to update/redo RFC 5277 at some point in time. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From andy@yumaworks.com Thu Jul 5 18:52:49 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD37911E8118 for ; Thu, 5 Jul 2012 18:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.23 X-Spam-Level: X-Spam-Status: No, score=-3.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwTZ1kIck5C1 for ; Thu, 5 Jul 2012 18:52:49 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29B3011E810B for ; Thu, 5 Jul 2012 18:52:49 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so14030746pbc.31 for ; Thu, 05 Jul 2012 18:53:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=zF9O+mJy9m24VO+aokzVQROkcWJGnFv/rNXrhoCt4S8=; b=ab1+ZsHOQNw2oh5pd55IVoOjlvmBjkGRBeq3X8AMOQ+VS/CHHWLq/lgR5JRH3b/b1w bH9PBk3Qi3PkTdHylVoi4KkDXXHGGEiY6mk2WvBLkqDplUdwicAPFnffDyBn7ffnfjNk WcBS0I5necXdLrixn982mn8r4h3VaP+s7D+XjHmjum7sXogArwzL5HzHSx0pyB4OrNnm RB5kM6R7GfSV1Xbb151Cer0WbdM3r+0FkSUINXPCtnbRqhBv8vbv72NkSrBKvEoQbqoO Dx0L2Zq9PKgIH+G5EpHjXkZHzrjfsqZTPUqrsVZoNDsIiyQ2shHhZXZpRrnwQOSW3re3 7FMw== Received: by 10.68.221.74 with SMTP id qc10mr32179556pbc.31.1341539584089; Thu, 05 Jul 2012 18:53:04 -0700 (PDT) Received: from [192.168.0.18] (cpe-75-84-168-164.socal.res.rr.com. [75.84.168.164]) by mx.google.com with ESMTPS id wf7sm20819879pbc.34.2012.07.05.18.53.01 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 18:53:02 -0700 (PDT) Message-ID: <4FF64504.6000909@yumaworks.com> Date: Thu, 05 Jul 2012 18:53:08 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <4FF2C373.5040806@mg-soft.com> <20120703115832.GA669@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403FCE65B@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403FCE65B@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlI9Dzw9AsVDZodxc4ZMj8kcuuBDDSinMX6M98W/v1eC9vvWkZkhZXiUTZ4ITq8BKYoAPOx Cc: netconf@ietf.org, NETMOD Working Group Subject: Re: [Netconf] [netmod] Modeling NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 01:52:49 -0000 On 07/03/2012 07:01 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > True. Is there any volunteer willing to yangify RFC 5277? Yes -- since I already started with notifications.yang and nc-notifications.yang. > > Mehmet Andy > > >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of ext >> Juergen Schoenwaelder >> Sent: Tuesday, July 03, 2012 1:59 PM >> To: Jernej Tuljak >> Cc: NETMOD Working Group >> Subject: Re: [netmod] Modeling NETCONF Event Notifications >> >> On Tue, Jul 03, 2012 at 12:03:31PM +0200, Jernej Tuljak wrote: >> >>> I have questions regarding NETCONF Notifications and YANG. Which >>> YANG module is the standard module that models RFC5277 >>> notifications? I've got nc-notifications@2008-07-14 >>> and notifications@2008-07-14 >>> over here, but it's quite evident >>> that they are part of yuma's netconfd. Are these what I'm looking >>> for? >> RFC 5277 predates the 'yangification' of the NETCONF specification and >> there likely is a need to update/redo RFC 5277 at some point in time. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Thu Jul 5 18:59:16 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8B511E8132 for ; Thu, 5 Jul 2012 18:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu4B3DtJgp5c for ; Thu, 5 Jul 2012 18:59:15 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1027811E812B for ; Thu, 5 Jul 2012 18:59:15 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so14038765pbc.31 for ; Thu, 05 Jul 2012 18:59:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=c/Fa6H0me971r6lpWeN/0z1BPWyW9oY+NGI9O5IJp6A=; b=FgrUp2y0+YqvaUaBHySTP/wNfbNy9VC4zmdqsiJ4BEXftOKYPa8BPHQlnOPZ9OG5OK W/VElqMqiYK7ON2rXqQ1kPoCv8jyFqJ/LQxFNHT5PR+JGo+oGKJEYf6hHdRtQlj+UhDD SNv6dJSxla2ziWcHaYjmU7M06eSSqqA94hJbjLhh5kZ5y3ljIzDGCSAFgoocyTdhN/2u Ft4wFklgOx2QbihIB4pnK39YGYGtNr9LiBlGNDkZ8Dj0JSFMdJWEU7GoqXUdNhm4haKd c6x0Y6UM9w6MD1OzSi0rmDCqZ6aioC5djHjyN7Y7N2BhXjX4GDunzGKLlqmHt4Lcc9ep J6hg== Received: by 10.68.193.226 with SMTP id hr2mr32644366pbc.155.1341539964307; Thu, 05 Jul 2012 18:59:24 -0700 (PDT) Received: from [192.168.0.18] (cpe-75-84-168-164.socal.res.rr.com. [75.84.168.164]) by mx.google.com with ESMTPS id ku7sm20830829pbc.31.2012.07.05.18.59.22 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 18:59:23 -0700 (PDT) Message-ID: <4FF64681.5060206@yumaworks.com> Date: Thu, 05 Jul 2012 18:59:29 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , Jernej Tuljak , netconf@ietf.org References: <4FF2C373.5040806@mg-soft.com> <20120703115832.GA669@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403FCE65B@DEMUEXC006.nsn-intra.net> <20120703142825.GC1361@elstar.local> In-Reply-To: <20120703142825.GC1361@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl46cNzvcS3cXe94RCKwOK1i0NeTiI3/tElVLWB8nNOUftyzD3bKucXVOdBUo/niOiWpSOw Subject: Re: [Netconf] [netmod] Modeling NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 01:59:16 -0000 On 07/03/2012 07:28 AM, Juergen Schoenwaelder wrote: > Hi, > > another option (in theory) would be to merge RFC 5277 into a future > version of NETCONF as a capability. Anyway, this seems to belong to > NETCONF space, so I remove NETMOD from the CC list. It already is 2 capabilities (:notification:1.0 and interleave:1.0). Let's keep that part stable. I agree the YANG modules for RFC 5277 do not have to be in RFC5277bis, but we like to do it that way so people have a clear picture way in advance what is changing. You know that if we open up RFC 5277, then people like me will suggest new features that customers have asked for ;-) E.g. -- source filtering -- the replay buffer is a ring buffer. There is no way for an operator to squelch a noisy event generator, especially for events that are minor or redundant. All these events go in the replay buffer and flood it, potentially over-writing important events already in the replay buffer. Another solution is to have multiple replay queues by priority. > /js Andy > > On Tue, Jul 03, 2012 at 04:01:33PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: >> True. Is there any volunteer willing to yangify RFC 5277? >> >> Mehmet >> >> >>> -----Original Message----- >>> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >> Behalf Of ext >>> Juergen Schoenwaelder >>> Sent: Tuesday, July 03, 2012 1:59 PM >>> To: Jernej Tuljak >>> Cc: NETMOD Working Group >>> Subject: Re: [netmod] Modeling NETCONF Event Notifications >>> >>> On Tue, Jul 03, 2012 at 12:03:31PM +0200, Jernej Tuljak wrote: >>> >>>> I have questions regarding NETCONF Notifications and YANG. Which >>>> YANG module is the standard module that models RFC5277 >>>> notifications? I've got nc-notifications@2008-07-14 >>>> and notifications@2008-07-14 >>>> over here, but it's quite evident >>>> that they are part of yuma's netconfd. Are these what I'm looking >>>> for? >>> RFC 5277 predates the 'yangification' of the NETCONF specification and >>> there likely is a need to update/redo RFC 5277 at some point in time. >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod From mehmet.ersue@nsn.com Sat Jul 7 10:38:19 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24DD21F8582 for ; Sat, 7 Jul 2012 10:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 460lk72d+uda for ; Sat, 7 Jul 2012 10:38:19 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 97A9D21F855D for ; Sat, 7 Jul 2012 10:38:18 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q67HcYc6008096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 7 Jul 2012 19:38:34 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q67HcYZR021001 for ; Sat, 7 Jul 2012 19:38:34 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 Jul 2012 19:38:34 +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 Date: Sat, 7 Jul 2012 19:38:33 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403FCF29B@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NomCom 2012-13 Call for Volunteers Thread-Index: Ac1cY6rvdkP+n5nsRban3U73JJu8bgAA39XA From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 07 Jul 2012 17:38:34.0528 (UTC) FILETIME=[55405A00:01CD5C67] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4083 X-purgate-ID: 151667::1341682714-0000425E-81C7BCD7/0-0/0-0 Subject: [Netconf] FW: NomCom 2012-13 Call for Volunteers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 17:38:19 -0000 Please consider volunteering, if you are eligible. Mehmet -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of ext Russ Housley Sent: Saturday, July 07, 2012 4:25 PM To: IETF Subject: Fwd: NomCom 2012-13 Call for Volunteers The NomCom process is critical for the proper function of the IETF. Please volunteer if you are eligible. Russ -------- Original Message -------- Subject: NomCom 2012-13 Call for Volunteers Date: Fri, 06 Jul 2012 14:15:33 -0700 From: NomCom Chair To: IETF Announcement List The IETF nominating committee process for 2012-13 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out. That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you qualify, and if you will not be seeking appointment to any of the open positions that this nomcom will be filling, please consider volunteering. The list of people whose terms end with the March 2013 IETF meeting, and thus the positions for which the nominating committee is responsible for filling, are as follows: IAOC: -------- Dave Crocker IAB: -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: -------- Russ Housley (General Area) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) The primary activity for this nomcom will begin in August 2012 and should be completed in January 2013. The nomcom will be collecting requirements from the community, as well as talking to candidates and obtaining feedback from community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 hours) August 5, 2012 as follows: To: mlepinski.ietf@gmail.com Subject: Nomcom 2012-13 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing toward that goal. I will be publishing a more detailed timetable for nomcom activities, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you, Matthew Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org From mehmet.ersue@nsn.com Wed Jul 18 07:15:45 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45BB21F876E for ; Wed, 18 Jul 2012 07:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCBCMXr57gtj for ; Wed, 18 Jul 2012 07:15:45 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id BEA9C21F869C for ; Wed, 18 Jul 2012 07:15:44 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6IEGWci025183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2012 16:16:32 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6IEGU8U013187; Wed, 18 Jul 2012 16:16:31 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jul 2012 16:16:31 +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 Date: Wed, 18 Jul 2012 16:16:02 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64040A388F@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft agenda for the NETCONF WG session Thread-Index: Ac1k79xOLeB1lqobSkKgMvj/llf3Ig== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 18 Jul 2012 14:16:31.0487 (UTC) FILETIME=[EDE658F0:01CD64EF] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 222 X-purgate-ID: 151667::1342620992-000055D8-E681333E/0-0/0-0 Subject: [Netconf] Draft agenda for the NETCONF WG session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:15:45 -0000 Hi All, below is the draft agenda for the NETCONF WG session in Vancouver: http://www.ietf.org/proceedings/84/agenda/agenda-84-netconf=20 Please send us your comments by July 24, 2012. Cheers,=20 Mehmet=20 From bwijnen@ripe.net Wed Jul 18 07:19:18 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AED21F872D for ; Wed, 18 Jul 2012 07:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCFkIz6aEScO for ; Wed, 18 Jul 2012 07:19:17 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id B4B6821F86D1 for ; Wed, 18 Jul 2012 07:19:16 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SrV6i-0008Rh-1K for netconf@ietf.org; Wed, 18 Jul 2012 16:20:06 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SrV6h-0008SV-RM for netconf@ietf.org; Wed, 18 Jul 2012 16:20:03 +0200 Message-ID: <5006C613.1@ripe.net> Date: Wed, 18 Jul 2012 16:20:03 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Netconf References: <5006C43A.2090509@ripe.net> In-Reply-To: <5006C43A.2090509@ripe.net> X-Forwarded-Message-Id: <5006C43A.2090509@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120718 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e074654c563cdd342bcc49fe9d2700d5f Subject: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:19:18 -0000 Dear WG participants, Please find below a first draft for a new WG charter. It takes into account the discussions we have had over the last half year or so. Please post your comments/objections/agreements (if at all possible) before the upcoming IETF mtg in Vancouver. We can then also further discuss it at that meeting. Possibly we should also add work on REST-API, but we believe that needs a bot more discussion first. Maybe we can add it based on our discussions in Vancouver. W.r.t. Netconf Lite: the WG obviously does not want a Netconf 2.0. The analysis of the discussion as well as the last direct response of WG members is rather positive than being negative. WG members are in general against 2.0 but most of them support 1.2 and don't have anything against N-L if the WG does it. Only a few are against 2.0 or any other change. Mehmet and Bert ---- draft netconf-charter-2012-jul-18-v2.txt ---------------------- Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org or: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group has produced a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors can provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses an XML-based data representation, that can be easily manipulated using non-specialized XML manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports multiple (e.g. candidate and running) data-stores to optimize configuration preparation and activation - Supports network wide configuration transactions (with features such as locking and rollback capability) - Runs over a secure transport; SSH is mandatory to implement while TLS, BEEP, and SOAP are optional transports. - Provides support for asynchronous notifications. - Supports an Access Control Model and a YANG module for configuring the Access Control parameters. - Supports a YANG module for System Notifications The NETCONF protocol has been designed independent of the data modeling language. The IETF recommends to use YANG as the NETCONF modeling language, which introduces advanced language features for configuration management. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. This means that RFC5593 needs to be updated. 2. To enable an implementation with a reduced code-size. There seems to be a need for a modular NETCONF solution (Netconf-Lite), which can be used e.g. in constrained devices or for an incremental deployment. The WG will create a document defining the minimal base of features for such a standard 3. RFC5277 (Netconf Event Notifications) was written before the YANG modeling language existed. The WG will "YANGify" that RFC, so that we have a proper YANG module for the Netconf Event Notifications. 4. Based on the implementation and deployment experience, the WG will document the status of NETCONF in order to advance the base documents (at least RFC6241 and RFC6242) on the standards track. 5. Since Netconf over BEEP and over SOAP seem not being deployed the WG will write a document that makes those 2 protocols (RFC4743 and RFC4744) HISTORIC. Goals and Milestones: done - Send with-defaults to IESG for consideration as Proposed Standard done - WG Last Call on rfc4741bis done - rfc4741bis to IESG for consideration as Proposed Standard done - Send rfc4742bis to IESG for consideration as proposed Standard. done - first WG draft (rev 00) on NACM posted done - first WG draft (rev 00) on NETCONF specific YANG modules posted done - WGLC for NACM document done - WGLC for NETCONF specific notifications document done - submit NACM document to IESG for consideration as Proposed Standard done - submit NETCONF specific notifications document to IESG for consideration as Proposed Standard aug 2012 - submit initial WG draft for rfc5539bis aug 2012 - submit initial WG draft for rfc5277bis aug 2012 - submit initial WG draft for Netconf Lite aug 2012 - submit initial WG draft for making RFC4743 and RFc4744 historic. sep 2012 - WGLC for rfc5539bis sep 2012 - WGLC for RFC4743 and 4743 to historic okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard okt 2012 - WGLC for rfc5277bis okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic okt 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 nov 2012 - Second WGLC for rfc5277bis (if needed) nov 2012 - WGLC for Netconf Lite nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience dec 2012 - submit rfc5277bis to AD/IESG for consideration as Proposed Standard dec 2012 - submit rfc5277bis to AD/IESG for consideration as Proposed Standard jan 2013 - second WGLC for Netconf Lite (if needed) jan 2013 - WGLC on RFC6241/6242 document to advance on standards track feb 2013 - submit Netconf Lite to AD/IESG for consideration as Proposed Standard feb 2013 - submit request to AD/IESG to advance RFC6241/6242 on Standards Track From andy@yumaworks.com Wed Jul 18 07:40:21 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7721F87A4 for ; Wed, 18 Jul 2012 07:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.955 X-Spam-Level: X-Spam-Status: No, score=-2.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oCztI-b0gWX for ; Wed, 18 Jul 2012 07:40:19 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 461F721F8769 for ; Wed, 18 Jul 2012 07:40:19 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2470412lbb.31 for ; Wed, 18 Jul 2012 07:41:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=i1VdAr+Gdk61nryEIDdWF+notn8A2FKlqVQhM/KH4EY=; b=PjRvxTiApKWRiEvwW+LO+wIuiR3cODYOZIGTN8KR1UkY/cNOHGccAk50jQs4E1f5x0 clKf2C8clHgSHdeMqDbN9fHb0edZiUTHIfCqwXTL/N3aJWHy3lFx6mZE2lC7SQM/4B1u U/+g3FlIfLLcTYp3WGe8DPywTZENRvpturFJD/at6u/8G5uPKai73rlajndhXtsslACb 0uhfJHu9dQarpUj1qGUjnKHcaqNw9ceDchVTIk4Cw3Sxv0pIQC0WlpNaSoIrz0m3Pxwf +Z5smaU5ieSqCgtzwgHzJIQHdZ5TgOk1L4sp1irVUvAf6jAVaMkEOGjg87FpqWoGeFqw HwEw== MIME-Version: 1.0 Received: by 10.112.36.132 with SMTP id q4mr1931897lbj.63.1342622468616; Wed, 18 Jul 2012 07:41:08 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 18 Jul 2012 07:41:08 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <5006C613.1@ripe.net> References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> Date: Wed, 18 Jul 2012 07:41:08 -0700 Message-ID: From: Andy Bierman To: Bert Wijnen Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl1jpk/QSW9tLx7MxwuxBW67TP4Fga7A7QAGzp/qoTSK7qDpIPIwJV0dQoDoexBaeE5xLqT Cc: Netconf Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:40:21 -0000 Hi, I have a few comments about the charter. I like the way (2) is stated. This is how customers have stated the problem to me. I've looked at (3) and will publish the Yuma YANG modules for this, except not the element. There is no way in YANG to have an 'anyxml' with a dynamic name (or complexType in XSD). There is no way to augment the element, just the event. This is consistent with rpc-stmt, so it should be OK. Is the WG going to deprecate RFC 6241 (i.e., create a base:1.2)? If so, what is the point of advancing 6241 on the standards track? Andy On Wed, Jul 18, 2012 at 7:20 AM, Bert Wijnen wrote: > > Dear WG participants, > > Please find below a first draft for a new WG charter. > > It takes into account the discussions we have had over > the last half year or so. > > Please post your comments/objections/agreements (if at > all possible) before the upcoming IETF mtg in Vancouver. > We can then also further discuss it at that meeting. > > Possibly we should also add work on REST-API, but we > believe that needs a bot more discussion first. Maybe we > can add it based on our discussions in Vancouver. > > W.r.t. Netconf Lite: > the WG obviously does not want a Netconf 2.0. The analysis of the > discussion as well as the last direct response of WG members is rather > positive than being negative. WG members are in general against 2.0 but > most of them support 1.2 and don't have anything against N-L if the WG > does it. Only a few are against 2.0 or any other change. > > Mehmet and Bert > > ---- draft netconf-charter-2012-jul-18-v2.txt ---------------------- > > Network Configuration (netconf) > ------------------------------- > > Charter > > Current Status: Active > > Chairs: > Bert Wijnen > Mehmet Ersue > > Operations and Management Area Directors: > Ronald Bonica > Benoit Claise > > Operations and Management Area Advisor: > Benoit Claise > > Mailing Lists: > General Discussion: netconf@ietf.org > To Subscribe: netconf-request@ietf.org > or: https://www.ietf.org/mailman/listinfo/netconf > Archive: http://www.ietf.org/mail-archive/web/netconf/ > > Description of Working Group: > > Configuration of networks of devices has become a critical requirement > for operators in today's highly interoperable networks. Operators from > large to small have developed their own mechanisms or used vendor > specific mechanisms to transfer configuration data to and from a > device, and for examining device state information which may impact > the configuration. Each of these mechanisms may be different in > various aspects, such as session establishment, user authentication, > configuration data exchange, and error responses. > > The NETCONF Working Group has produced a protocol suitable for > network configuration, with the following characteristics: > > - Provides retrieval mechanisms which can differentiate between > configuration data and non-configuration data > - Is extensible enough so that vendors can provide access to all > configuration data on the device using a single protocol > - Has a programmatic interface (avoids screen scraping and > formatting-related changes between releases) > - Uses an XML-based data representation, that can be easily manipulated > using non-specialized XML manipulation tools. > - Supports integration with existing user authentication methods > - Supports integration with existing configuration database systems > - Supports multiple (e.g. candidate and running) data-stores to > optimize configuration preparation and activation > - Supports network wide configuration transactions (with features such > as locking and rollback capability) > - Runs over a secure transport; SSH is mandatory to implement while TLS, > BEEP, and SOAP are optional transports. > - Provides support for asynchronous notifications. > - Supports an Access Control Model and a YANG module for configuring > the Access Control parameters. > - Supports a YANG module for System Notifications > > The NETCONF protocol has been designed independent of the data modeling > language. The IETF recommends to use YANG as the NETCONF modeling > language, which introduces advanced language features for configuration > management. > > In the current phase of the incremental development of NETCONF the > workgroup will focus on following items: > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > > This means that RFC5593 needs to be updated. > > 2. To enable an implementation with a reduced code-size. > > There seems to be a need for a modular NETCONF solution > (Netconf-Lite), which can be used e.g. in constrained > devices or for an incremental deployment. > The WG will create a document defining the minimal base > of features for such a standard > > 3. RFC5277 (Netconf Event Notifications) was written before the > YANG modeling language existed. The WG will "YANGify" that > RFC, so that we have a proper YANG module for the Netconf > Event Notifications. > > 4. Based on the implementation and deployment experience, the WG > will document the status of NETCONF in order to advance the > base documents (at least RFC6241 and RFC6242) on the standards > track. > > 5. Since Netconf over BEEP and over SOAP seem not being deployed > the WG will write a document that makes those 2 protocols > (RFC4743 and RFC4744) HISTORIC. > > Goals and Milestones: > done - Send with-defaults to IESG for consideration as Proposed > Standard > done - WG Last Call on rfc4741bis > done - rfc4741bis to IESG for consideration as Proposed Standard > done - Send rfc4742bis to IESG for consideration as proposed Standard. > done - first WG draft (rev 00) on NACM posted > done - first WG draft (rev 00) on NETCONF specific YANG modules posted > done - WGLC for NACM document > done - WGLC for NETCONF specific notifications document > done - submit NACM document to IESG for consideration as Proposed > Standard > done - submit NETCONF specific notifications document to IESG for > consideration as Proposed Standard > aug 2012 - submit initial WG draft for rfc5539bis > aug 2012 - submit initial WG draft for rfc5277bis > aug 2012 - submit initial WG draft for Netconf Lite > aug 2012 - submit initial WG draft for making RFC4743 and RFc4744 > historic. > sep 2012 - WGLC for rfc5539bis > sep 2012 - WGLC for RFC4743 and 4743 to historic > okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed > Standard > okt 2012 - WGLC for rfc5277bis > okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > okt 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > nov 2012 - Second WGLC for rfc5277bis (if needed) > nov 2012 - WGLC for Netconf Lite > nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment > experience > dec 2012 - submit rfc5277bis to AD/IESG for consideration as Proposed > Standard > dec 2012 - submit rfc5277bis to AD/IESG for consideration as Proposed > Standard > jan 2013 - second WGLC for Netconf Lite (if needed) > jan 2013 - WGLC on RFC6241/6242 document to advance on standards track > feb 2013 - submit Netconf Lite to AD/IESG for consideration as Proposed > Standard > feb 2013 - submit request to AD/IESG to advance RFC6241/6242 on Standards > Track > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bwijnen@ripe.net Wed Jul 18 07:42:58 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5076421F87AF for ; Wed, 18 Jul 2012 07:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjoOFDGNtB1u for ; Wed, 18 Jul 2012 07:42:57 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id AEFFD21F87AB for ; Wed, 18 Jul 2012 07:42:57 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SrVTe-0000Oq-Pl; Wed, 18 Jul 2012 16:43:47 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SrVTe-0000mG-If; Wed, 18 Jul 2012 16:43:46 +0200 Message-ID: <5006CBA2.1040806@ripe.net> Date: Wed, 18 Jul 2012 16:43:46 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andy Bierman References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120718 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e94551e3a8ad58201c0b5bea8ce307520 Cc: Netconf Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:42:58 -0000 On 7/18/12 4:41 PM, Andy Bierman wrote: > Hi, > > I have a few comments about the charter. > > I like the way (2) is stated. This is how customers have stated > the problem to me. > > I've looked at (3) and will publish the Yuma YANG modules for this, > except not the element. There is no way in YANG > to have an 'anyxml' with a dynamic name (or complexType in XSD). > There is no way to augment the element, just the event. > This is consistent with rpc-stmt, so it should be OK. > > Is the WG going to deprecate RFC 6241 (i.e., create a base:1.2)? > If so, what is the point of advancing 6241 on the standards track? > Depends on how we exactly define Netconf Lite. If it becomes a 1.2 which obsoletes 6241, then sure we cannot advance 6241. Bert > > > Andy > > From mehmet.ersue@nsn.com Wed Jul 18 07:53:52 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC1D21F8694 for ; Wed, 18 Jul 2012 07:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAsgyOikvvhR for ; Wed, 18 Jul 2012 07:53:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id EF1D321F8687 for ; Wed, 18 Jul 2012 07:53:51 -0700 (PDT) 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 q6IEsdem023922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2012 16:54:39 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6IEsd6O025373; Wed, 18 Jul 2012 16:54:39 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jul 2012 16:54:38 +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 Date: Wed, 18 Jul 2012 16:54:24 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64040A38D2@DEMUEXC006.nsn-intra.net> In-Reply-To: <5006CBA2.1040806@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] draft updated NETCONF WG charter Thread-Index: Ac1k88aPTtPUXLYgQ5uw0dpmYNHabQAAPsgA References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> <5006CBA2.1040806@ripe.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert Wijnen" , "Andy Bierman" X-OriginalArrivalTime: 18 Jul 2012 14:54:38.0798 (UTC) FILETIME=[413E4EE0:01CD64F5] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 341 X-purgate-ID: 151667::1342623279-000055D8-F4CE4EB0/0-0/0-0 Cc: Netconf Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:53:53 -0000 > > Is the WG going to deprecate RFC 6241 (i.e., create a base:1.2)? > > If so, what is the point of advancing 6241 on the standards track? > > > Depends on how we exactly define Netconf Lite. If it becomes a 1.2 > which obsoletes 6241, then sure we cannot advance 6241. My understanding is that Netconf-Lite is not 1.2. Mehmet From j.schoenwaelder@jacobs-university.de Wed Jul 18 08:00:47 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581FC21F85D4 for ; Wed, 18 Jul 2012 08:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2g7cOG9QkJT for ; Wed, 18 Jul 2012 08:00:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE4B21F85C3 for ; Wed, 18 Jul 2012 08:00:46 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9459320BD7; Wed, 18 Jul 2012 17:01:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sOgGPOawvBsf; Wed, 18 Jul 2012 17:01:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E12D120BD6; Wed, 18 Jul 2012 17:01:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B6C2120A8979; Wed, 18 Jul 2012 17:01:33 +0200 (CEST) Date: Wed, 18 Jul 2012 17:01:32 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20120718150132.GA54638@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Bert Wijnen , Andy Bierman , Netconf References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> <5006CBA2.1040806@ripe.net> <80A0822C5E9A4440A5117C2F4CD36A64040A38D2@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64040A38D2@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ext Bert Wijnen , Netconf Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:00:47 -0000 On Wed, Jul 18, 2012 at 04:54:24PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > Is the WG going to deprecate RFC 6241 (i.e., create a base:1.2)? > > > If so, what is the point of advancing 6241 on the standards track? > > > > > Depends on how we exactly define Netconf Lite. If it becomes a 1.2 > > which obsoletes 6241, then sure we cannot advance 6241. > > My understanding is that Netconf-Lite is not 1.2. Are you talking as co-chair or as contributor? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Wed Jul 18 08:07:33 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C4021F8623 for ; Wed, 18 Jul 2012 08:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.955 X-Spam-Level: X-Spam-Status: No, score=-2.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKRs0JB6qpiy for ; Wed, 18 Jul 2012 08:07:33 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D24AA21F8610 for ; Wed, 18 Jul 2012 08:07:32 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2504378lbb.31 for ; Wed, 18 Jul 2012 08:08:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=SggRsQ+5+JlV+L7UV6V7Zf0YnHjVl0rwf7Y5t51Rtf4=; b=Scpo8sbXJjKDk3i/8ZdtzQceDmka35t/7s1I2TtoSZhawuOjpBcg07NDBaL6r6JVjf 7q/Xa05YAu/I0m8Dj68fbxx2TR/dGrt7quA+lLdE4khZqY+kjD8dTPrkVrRxEFfLZAJt ySKj6o/PUN1FwPyqSt10KWmHWVgxYZ55098z+Wqb83S5DHB8i1NClJFUxglMYYjMoyLL xgTxbfyR5fXHeV3/QEB3vFEKdnnoYtJr+Ibz16RhAmZLcaR4gRnB3NLBnh6IWDG5D+6K Ll8cokWk2ENHnW/EIFsl/58ZAs2w3uzqTYfmLteOQqtKX7mQHhHV0ysvaaVGfxSnuBxo iPGA== MIME-Version: 1.0 Received: by 10.152.113.199 with SMTP id ja7mr3942676lab.10.1342624102548; Wed, 18 Jul 2012 08:08:22 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 18 Jul 2012 08:08:22 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64040A38D2@DEMUEXC006.nsn-intra.net> References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> <5006CBA2.1040806@ripe.net> <80A0822C5E9A4440A5117C2F4CD36A64040A38D2@DEMUEXC006.nsn-intra.net> Date: Wed, 18 Jul 2012 08:08:22 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnuDhwCQO/wivc+twg09H7/WTnLiSzD56R/IlW75bxtDwf/amo/N++SLg/OVGoeufdeyWqH Cc: ext Bert Wijnen , Netconf Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:07:33 -0000 On Wed, Jul 18, 2012 at 7:54 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: >> > Is the WG going to deprecate RFC 6241 (i.e., create a base:1.2)? >> > If so, what is the point of advancing 6241 on the standards track? >> > >> Depends on how we exactly define Netconf Lite. If it becomes a 1.2 >> which obsoletes 6241, then sure we cannot advance 6241. > > My understanding is that Netconf-Lite is not 1.2. > Good. It's time to advance base:1.1 to DS. I agree with Phil that deploying 1.1 should be the main goal. It may not be possible to cleanly keep base:1.1 and netconf-lite completely separate. Since session startup is so expensive in SSH, we really do not want to make updated clients connect twice to talk to a lite server. E.g., send a with base:1.0 and base:1.1, have the server drop the session, then retry with the netconf-lite . > Mehmet > Andy From andy@yumaworks.com Wed Jul 18 08:12:46 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205B721F86DC for ; Wed, 18 Jul 2012 08:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgjV3-ZrY9jD for ; Wed, 18 Jul 2012 08:12:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2010A21F86D6 for ; Wed, 18 Jul 2012 08:12:44 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2511154lbb.31 for ; Wed, 18 Jul 2012 08:13:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=CKEJneBoYaIAz7iK2QXRbM9CIWOQLWplAq3xLNkVOa0=; b=dZhztGNo47ikEN4+TWUqbMtjYeOJBZx7rtZU5nCuiZNUAy2zm43mpsI52YovcGitPO HaQRxjCbLIcPF03WYow54G4JCkQK4dsyPVAs+btz2ffp5oeWei/CVu8jZmOeZPo2CBBb j0e3VfhxCXs1z6Zny+ZUKnYtTWeNWx5glqRMYn1LVx4QmbFp6qrxk7N4/aqg7Ap9wMCa wx5PiaYmo+8zCu/aNVEHSwCnA7XA+5gKTQaznG+LpvxxIeaAGk3kYlEMmP0P/oyOyTz2 AuxCqJCUfpqVA1VBN+T4bM3NS6mBWpnY9jkwsTQgVdwztaTHY54JanyViv37NpJdKuiy rvqw== MIME-Version: 1.0 Received: by 10.112.86.132 with SMTP id p4mr1971810lbz.22.1342624414717; Wed, 18 Jul 2012 08:13:34 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 18 Jul 2012 08:13:34 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> <5006CBA2.1040806@ripe.net> <80A0822C5E9A4440A5117C2F4CD36A64040A38D2@DEMUEXC006.nsn-intra.net> Date: Wed, 18 Jul 2012 08:13:34 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlzSKqCasB7V3IQyhnrFVagqeTOqLPIcMMbRMZS18BRkrNjrzM/DIUxrcfuRNJgdDkBHq0o Cc: ext Bert Wijnen , Netconf Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:12:46 -0000 On Wed, Jul 18, 2012 at 8:08 AM, Andy Bierman wrote: > On Wed, Jul 18, 2012 at 7:54 AM, Ersue, Mehmet (NSN - DE/Munich) > wrote: >>> > Is the WG going to deprecate RFC 6241 (i.e., create a base:1.2)? >>> > If so, what is the point of advancing 6241 on the standards track? >>> > >>> Depends on how we exactly define Netconf Lite. If it becomes a 1.2 >>> which obsoletes 6241, then sure we cannot advance 6241. >> >> My understanding is that Netconf-Lite is not 1.2. >> > > Good. It's time to advance base:1.1 to DS. oops -- there is no Draft Standard anymore right? (I have to pay more attention to the ietf list.) So we would have to meet the 'widely deployed' criteria? I don't think we are there yet. Can somebody clarify what the WG needs to do to advance base:1.1 in the new standards track? Andy From j.schoenwaelder@jacobs-university.de Wed Jul 18 08:43:46 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F4511E80A4 for ; Wed, 18 Jul 2012 08:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVBmUhbSK7In for ; Wed, 18 Jul 2012 08:43:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 373E921F8659 for ; Wed, 18 Jul 2012 08:43:45 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59DF02095C; Wed, 18 Jul 2012 17:44:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id R4GDy1Y_qYN9; Wed, 18 Jul 2012 17:44:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B87D620933; Wed, 18 Jul 2012 17:44:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 40E6B20A8B27; Wed, 18 Jul 2012 17:44:33 +0200 (CEST) Date: Wed, 18 Jul 2012 17:44:33 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120718154433.GA54844@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , ext Bert Wijnen , Netconf References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> <5006CBA2.1040806@ripe.net> <80A0822C5E9A4440A5117C2F4CD36A64040A38D2@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ext Bert Wijnen , Netconf Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:43:46 -0000 On Wed, Jul 18, 2012 at 08:13:34AM -0700, Andy Bierman wrote: > On Wed, Jul 18, 2012 at 8:08 AM, Andy Bierman wrote: > > On Wed, Jul 18, 2012 at 7:54 AM, Ersue, Mehmet (NSN - DE/Munich) > > wrote: > >>> > Is the WG going to deprecate RFC 6241 (i.e., create a base:1.2)? > >>> > If so, what is the point of advancing 6241 on the standards track? > >>> > > >>> Depends on how we exactly define Netconf Lite. If it becomes a 1.2 > >>> which obsoletes 6241, then sure we cannot advance 6241. > >> > >> My understanding is that Netconf-Lite is not 1.2. > >> > > > > Good. It's time to advance base:1.1 to DS. > > oops -- there is no Draft Standard anymore right? > (I have to pay more attention to the ietf list.) > So we would have to meet the 'widely deployed' criteria? > I don't think we are there yet. > > Can somebody clarify what the WG needs to do to advance base:1.1 > in the new standards track? I suggest RFC 6410, in particular section 2.2. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bwijnen@ripe.net Wed Jul 18 08:47:57 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8756C21F86BD for ; Wed, 18 Jul 2012 08:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RoMAZGuQN-D for ; Wed, 18 Jul 2012 08:47:57 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id A9C5A21F8697 for ; Wed, 18 Jul 2012 08:47:56 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SrWUW-0000BR-Vu; Wed, 18 Jul 2012 17:48:46 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SrWUW-0007Jw-QH; Wed, 18 Jul 2012 17:48:44 +0200 Message-ID: <5006DADC.8030309@ripe.net> Date: Wed, 18 Jul 2012 17:48:44 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> <5006CBA2.1040806@ripe.net> <80A0822C5E9A4440A5117C2F4CD36A64040A38D2@DEMUEXC006.nsn-intra.net> <20120718154433.GA54844@elstar.local> In-Reply-To: <20120718154433.GA54844@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120718 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885ed09908642f5df7f4b918a0f37533344d Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:47:57 -0000 On 7/18/12 5:44 PM, Juergen Schoenwaelder wrote: > On Wed, Jul 18, 2012 at 08:13:34AM -0700, Andy Bierman wrote: >> On Wed, Jul 18, 2012 at 8:08 AM, Andy Bierman wrote: >>> On Wed, Jul 18, 2012 at 7:54 AM, Ersue, Mehmet (NSN - DE/Munich) >>> wrote: >>>>>> Is the WG going to deprecate RFC 6241 (i.e., create a base:1.2)? >>>>>> If so, what is the point of advancing 6241 on the standards track? >>>>>> >>>>> Depends on how we exactly define Netconf Lite. If it becomes a 1.2 >>>>> which obsoletes 6241, then sure we cannot advance 6241. >>>> >>>> My understanding is that Netconf-Lite is not 1.2. >>>> >>> >>> Good. It's time to advance base:1.1 to DS. >> >> oops -- there is no Draft Standard anymore right? >> (I have to pay more attention to the ietf list.) >> So we would have to meet the 'widely deployed' criteria? >> I don't think we are there yet. >> >> Can somebody clarify what the WG needs to do to advance base:1.1 >> in the new standards track? > > I suggest RFC 6410, in particular section 2.2. > \ Right. It says: (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. (3) There are no unused features in the specification that greatly increase implementation complexity. (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. We may have a hard time proving "widespread deployment". Other than that? I think we're fine. So... do we believe we have "widespread deployment"? The term is not defined explicitly, so I take it as something that is subjective. I would say that netconf is as widely deployed as some features of SNMPv3. But that is just my opinion. bert > /js > From andy@yumaworks.com Wed Jul 18 09:15:11 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83ED21F878B for ; Wed, 18 Jul 2012 09:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj3YoxQeF7cR for ; Wed, 18 Jul 2012 09:15:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 892A721F8792 for ; Wed, 18 Jul 2012 09:15:10 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2583947lbb.31 for ; Wed, 18 Jul 2012 09:16:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XFiRzjoJHTwATTmsSjYZGNhEX12EwUFEo4f3wwYneyA=; b=K6Z0/c2AkU1Gh9yc1xNXSFoioZmzN/d3g22ATMIkbJIbPZ1UC1ceFi4dubSGfJl7Om GiummR2uTyvTYs7va9q+gwewQWUCJOdNj+Isn+eICjiZEEFzKn6ZPncsIHVVyPUa6Ci7 347qjVuRCf/2ZUdkr/XRbtpx6pOWXF3VpINAQcE9i0G1kCqwv8ICx0l0i1w92LXVDIPf liJjEuF1DK1QR7rtwtNSY2j8SP7D4iVqSFhi1qDbsPx/4gF0yWcXciaTarSXlqX/zKO5 ugJOtsxm0mSWth6cBoYkUh9abgFy5JaZDfJ3UPZ/972BBlUVCjHBNhff5qHYLTMgcayp 0kxw== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr4069941lab.47.1342628160370; Wed, 18 Jul 2012 09:16:00 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 18 Jul 2012 09:16:00 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <5006DADC.8030309@ripe.net> References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> <5006CBA2.1040806@ripe.net> <80A0822C5E9A4440A5117C2F4CD36A64040A38D2@DEMUEXC006.nsn-intra.net> <20120718154433.GA54844@elstar.local> <5006DADC.8030309@ripe.net> Date: Wed, 18 Jul 2012 09:16:00 -0700 Message-ID: From: Andy Bierman To: Bert Wijnen Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkn73kVHyKIQP08GhSO9q5a/EEQ7iXvphrSb11j3Fkcmrk2qxswtwUcX0WqqvM1Edyamsqj Cc: Netconf Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:15:11 -0000 On Wed, Jul 18, 2012 at 8:48 AM, Bert Wijnen wrote: > On 7/18/12 5:44 PM, Juergen Schoenwaelder wrote: >> >> On Wed, Jul 18, 2012 at 08:13:34AM -0700, Andy Bierman wrote: >>> >>> On Wed, Jul 18, 2012 at 8:08 AM, Andy Bierman wrote: >>>> >>>> On Wed, Jul 18, 2012 at 7:54 AM, Ersue, Mehmet (NSN - DE/Munich) >>>> wrote: >>>>>>> >>>>>>> Is the WG going to deprecate RFC 6241 (i.e., create a base:1.2)? >>>>>>> If so, what is the point of advancing 6241 on the standards track? >>>>>>> >>>>>> Depends on how we exactly define Netconf Lite. If it becomes a 1.2 >>>>>> which obsoletes 6241, then sure we cannot advance 6241. >>>>> >>>>> >>>>> My understanding is that Netconf-Lite is not 1.2. >>>>> >>>> >>>> Good. It's time to advance base:1.1 to DS. >>> >>> >>> oops -- there is no Draft Standard anymore right? >>> (I have to pay more attention to the ietf list.) >>> So we would have to meet the 'widely deployed' criteria? >>> I don't think we are there yet. >>> >>> Can somebody clarify what the WG needs to do to advance base:1.1 >>> in the new standards track? >> >> >> I suggest RFC 6410, in particular section 2.2. >> \ > > > Right. It says: > (1) There are at least two independent interoperating implementations > with widespread deployment and successful operational experience. > > (2) There are no errata against the specification that would cause a > new implementation to fail to interoperate with deployed ones. > > (3) There are no unused features in the specification that greatly > increase implementation complexity. > > (4) If the technology required to implement the specification > requires patented or otherwise controlled technology, then the > set of implementations must demonstrate at least two independent, > separate and successful uses of the licensing process. > OK -- I remember reading all this in I-D form. I would say that we might meet all these requirements by now. Between ncclient, yuma, and tail-f products there are multiple servers working with multiple clients. I think we would still need to document an actual interoperability test, like we used to do for SNMP, RMON, etc. > We may have a hard time proving "widespread deployment". You WG chairs can beg and plead for companies to send implementation reports (like the old days). Most will ignore you, but a few might respond. ;-) > Other than that? I think we're fine. So... do we believe we > have "widespread deployment"? The term is not defined explicitly, > so I take it as something that is subjective. > > I would say that netconf is as widely deployed as some features of > SNMPv3. But that is just my opinion. > > bert > >> /js >> > > Andy From mbj@tail-f.com Wed Jul 18 13:47:20 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2D311E814A for ; Wed, 18 Jul 2012 13:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnVGGjx9IGpk for ; Wed, 18 Jul 2012 13:47:19 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BEE2A11E80AA for ; Wed, 18 Jul 2012 13:47:19 -0700 (PDT) Received: from localhost (213-65-181-96-no181.tbcn.telia.com [213.65.181.96]) by mail.tail-f.com (Postfix) with ESMTPSA id 8BED31200CB1; Wed, 18 Jul 2012 22:48:09 +0200 (CEST) Date: Wed, 18 Jul 2012 22:48:08 +0200 (CEST) Message-Id: <20120718.224808.231495970.mbj@tail-f.com> To: bwijnen@ripe.net From: Martin Bjorklund In-Reply-To: <5006C613.1@ripe.net> References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 20:47:20 -0000 Hi, Bert Wijnen wrote: > W.r.t. Netconf Lite: > the WG obviously does not want a Netconf 2.0. The analysis of the > discussion as well as the last direct response of WG members is rather > positive than being negative. WG members are in general against 2.0 but > most of them support 1.2 and don't have anything against N-L if the WG > does it. Only a few are against 2.0 or any other change. Mehmet then wrote: My understanding is that Netconf-Lite is not 1.2. Juergen's original proposal was a separate protocol, not even NETCONF 1.2, which I believe is what Mehmet is also suggesting. But this seems to contradict what Bert wrote above. Personally, I do not think that NETCONF light is top prio, but if we do it, I would rather see it as a separate protocol, than 1.2 or 2.0 of NETCONF. > 3. RFC5277 (Netconf Event Notifications) was written before the > YANG modeling language existed. The WG will "YANGify" that > RFC, so that we have a proper YANG module for the Netconf > Event Notifications. Do we have to be on-the-wire compatible with 5277? I.e., should the charter be explicit about this - either state that we must be compatible, or say that we don't have to be. 5277 defines the unfortunate "netconf" container in the namespace "urn:ietf:params:xml:ns:netmod:notification". The standard notifications "replayComplete" and "notificationComplate" are also defined in this namespace. Not to be confused with the namespace "urn:ietf:params:xml:ns:netconf:notification:1.0" which defines the operation "createSubscription"! I also think that Andy's ideas around configuration of streams would be interesting to look at. (this probably needs more time though) /martin From andy@yumaworks.com Wed Jul 18 14:05:46 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6EA11E81A8 for ; Wed, 18 Jul 2012 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pc7ewpSLjI9F for ; Wed, 18 Jul 2012 14:05:45 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4676111E8087 for ; Wed, 18 Jul 2012 14:05:45 -0700 (PDT) Received: by bkty7 with SMTP id y7so1814719bkt.31 for ; Wed, 18 Jul 2012 14:06:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=iJE0AETGPPXQDloEJKiURyeoND9pcu7YYhMz1yIv2iY=; b=ZWCb5hjaPhaIk4FRX07dyXT/i0Xplmgr8wd3rJaeZR9IfXnohWPhqgbSYngjNizVQP EWb0yCa4mvSkbhyhzjVI5S+AFNk4edhC1nNY3RLGn9qGFRXvmqzMsa0KuFXmoZ0WXi/z Iq8dMV4dAmjHXLIzACbmPXCYf9HFLn7X7okYcBURIYcZ1Wai3SD/x/+lhpzaAKbp+/3l bqzi8fy9tVLFs/9+mIrEyqHrdwLMdPyzKlnplI8AFbZFwZzOMubfwFJcQlnnq2kkavtb vNU2TE3GvbGzxUjFb4JybjS5yZ1OT4sGu1fyqo0b1HX20j50O0reU6YbAnOEQGwqco2/ WQFA== MIME-Version: 1.0 Received: by 10.152.144.99 with SMTP id sl3mr5132360lab.44.1342645595701; Wed, 18 Jul 2012 14:06:35 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 18 Jul 2012 14:06:35 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120718.224808.231495970.mbj@tail-f.com> References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> <20120718.224808.231495970.mbj@tail-f.com> Date: Wed, 18 Jul 2012 14:06:35 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmxgCsp1kWCX177r7UzanHVqZDyHbiDFHXA0rQrcvwLPsqsRZ7AjrRFfwbGHKH0cacR7FtK Cc: bwijnen@ripe.net, netconf@ietf.org Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 21:05:46 -0000 On Wed, Jul 18, 2012 at 1:48 PM, Martin Bjorklund wrote: > Hi, > > Bert Wijnen wrote: >> W.r.t. Netconf Lite: >> the WG obviously does not want a Netconf 2.0. The analysis of the >> discussion as well as the last direct response of WG members is rather >> positive than being negative. WG members are in general against 2.0 but >> most of them support 1.2 and don't have anything against N-L if the WG >> does it. Only a few are against 2.0 or any other change. > > Mehmet then wrote: > > My understanding is that Netconf-Lite is not 1.2. > > Juergen's original proposal was a separate protocol, not even NETCONF > 1.2, which I believe is what Mehmet is also suggesting. But this > seems to contradict what Bert wrote above. > > Personally, I do not think that NETCONF light is top prio, but if we > do it, I would rather see it as a separate protocol, than 1.2 or 2.0 > of NETCONF. Agreed > >> 3. RFC5277 (Netconf Event Notifications) was written before the >> YANG modeling language existed. The WG will "YANGify" that >> RFC, so that we have a proper YANG module for the Netconf >> Event Notifications. > > Do we have to be on-the-wire compatible with 5277? I.e., should the > charter be explicit about this - either state that we must be > compatible, or say that we don't have to be. > > 5277 defines the unfortunate "netconf" container in the namespace > "urn:ietf:params:xml:ns:netmod:notification". The standard > notifications "replayComplete" and "notificationComplate" are also > defined in this namespace. Not to be confused with the namespace > "urn:ietf:params:xml:ns:netconf:notification:1.0" which defines the > operation "createSubscription"! > > I also think that Andy's ideas around configuration of streams would > be interesting to look at. (this probably needs more time though) > There seems to be a lower bound on completion time in the IETF, like minimum packet size. You might as well fill the packet if it's going to take the same amount of time either way. ;-) I prefer not to open any existing RFC unless we are prepared to improve it based on deployment experience. I prefer not to decide it advance the exact sections of text that might change, or if a notification:1.1 capability is needed, etc. > > /martin Andy From bertietf@bwijnen.net Thu Jul 19 00:07:55 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4256D11E808A for ; Thu, 19 Jul 2012 00:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHeY4Y4gfI9h for ; Thu, 19 Jul 2012 00:07:54 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id B9F9B21F8637 for ; Thu, 19 Jul 2012 00:07:53 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Srkqp-0001rn-38; Thu, 19 Jul 2012 09:08:44 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest23.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Srkqo-00009M-VC; Thu, 19 Jul 2012 09:08:43 +0200 Message-ID: <5007B280.3060605@bwijnen.net> Date: Thu, 19 Jul 2012 09:08:48 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Martin Bjorklund References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> <20120718.224808.231495970.mbj@tail-f.com> In-Reply-To: <20120718.224808.231495970.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120719 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd45cf42bb9d5b134c8276a9bf89e4a9293 Cc: netconf@ietf.org Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 07:07:55 -0000 Inline On 7/18/12 10:48 PM, Martin Bjorklund wrote: > Hi, > > Bert Wijnen wrote: >> W.r.t. Netconf Lite: >> the WG obviously does not want a Netconf 2.0. The analysis of the >> discussion as well as the last direct response of WG members is rather >> positive than being negative. WG members are in general against 2.0 but >> most of them support 1.2 and don't have anything against N-L if the WG >> does it. Only a few are against 2.0 or any other change. > > Mehmet then wrote: > > My understanding is that Netconf-Lite is not 1.2. > > Juergen's original proposal was a separate protocol, not even NETCONF > 1.2, which I believe is what Mehmet is also suggesting. But this > seems to contradict what Bert wrote above. > Separate is fine by me too. And that would nicely allow us to possinly advance rfc6241/42 > Personally, I do not think that NETCONF light is top prio, but if we > do it, I would rather see it as a separate protocol, than 1.2 or 2.0 > of NETCONF. > >> 3. RFC5277 (Netconf Event Notifications) was written before the >> YANG modeling language existed. The WG will "YANGify" that >> RFC, so that we have a proper YANG module for the Netconf >> Event Notifications. > > Do we have to be on-the-wire compatible with 5277? I.e., should the > charter be explicit about this - either state that we must be > compatible, or say that we don't have to be. > > 5277 defines the unfortunate "netconf" container in the namespace > "urn:ietf:params:xml:ns:netmod:notification". The standard > notifications "replayComplete" and "notificationComplate" are also > defined in this namespace. Not to be confused with the namespace > "urn:ietf:params:xml:ns:netconf:notification:1.0" which defines the > operation "createSubscription"! > > I also think that Andy's ideas around configuration of streams would > be interesting to look at. (this probably needs more time though) > We (WG chairs) would like to hear opinions on what kind of things we want to change if we indeed do open up 5277. If it is more than YANGifying, then maybe our usggested milestones for this item are a bit too aggressive. Bert > > /martin From mehmet.ersue@nsn.com Thu Jul 19 03:57:25 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4311F21F875C for ; Thu, 19 Jul 2012 03:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8UAbAg8TJDP for ; Thu, 19 Jul 2012 03:57:24 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB5B21F85E3 for ; Thu, 19 Jul 2012 03:57:24 -0700 (PDT) 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 q6JAwFix011638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Jul 2012 12:58:15 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6JAwDMU018005; Thu, 19 Jul 2012 12:58:15 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jul 2012 12:58:13 +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 Date: Thu, 19 Jul 2012 12:57:21 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64040A3BC1@DEMUEXC006.nsn-intra.net> In-Reply-To: <5007B280.3060605@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] draft updated NETCONF WG charter Thread-Index: Ac1lfVqGmyeNxNU4Rq+WMekiiebzEwAHM0Jw References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net><20120718.224808.231495970.mbj@tail-f.com> <5007B280.3060605@bwijnen.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert Wijnen (IETF)" , "Martin Bjorklund" , "Juergen Schoenwaelder" , "Andy Bierman" X-OriginalArrivalTime: 19 Jul 2012 10:58:13.0502 (UTC) FILETIME=[648FA9E0:01CD659D] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1379 X-purgate-ID: 151667::1342695495-000055D8-E351C390/0-0/0-0 Cc: netconf@ietf.org Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 10:57:25 -0000 > >> W.r.t. Netconf Lite: > >> the WG obviously does not want a Netconf 2.0. The analysis of the > >> discussion as well as the last direct response of WG members is rather > >> positive than being negative. WG members are in general against 2.0 but > >> most of them support 1.2 and don't have anything against N-L if the WG > >> does it. Only a few are against 2.0 or any other change. > > > > Mehmet then wrote: > > > > My understanding is that Netconf-Lite is not 1.2. > > > > Juergen's original proposal was a separate protocol, not even NETCONF > > 1.2, which I believe is what Mehmet is also suggesting. But this > > seems to contradict what Bert wrote above. As a co-chair and contributor I differentiate between Netconf-Lite and 1.2. IOW somebody who wants Netconf-Lite to be equally the same as 1.2, needs to state this explicitly.=20 The description above is as difficult as the long discussion on the maillist was. Different persons have seen different overlapping between the acronyms 2.0, 1.2, 1.1 and N-L. At the end of the day we need to proceed. So I fully agree with and support the advancement of 1.1. If the WG approves the charter proposal we can do Netconf-Lite too. BTW: I assume we also need to care bullet (4) in section 2.2. of 6410. http://www.ietf.org/mail-archive/web/netconf/current/msg07621.html=20 Mehmet From andy@yumaworks.com Thu Jul 19 04:10:33 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB9221F8768 for ; Thu, 19 Jul 2012 04:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjLTJOQSqsAO for ; Thu, 19 Jul 2012 04:10:33 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C77B21F8766 for ; Thu, 19 Jul 2012 04:10:32 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3841628lbb.31 for ; Thu, 19 Jul 2012 04:11:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=wAP6jT59iYirtUgGyjFB1uXgEucAsXXt1/77DDh5oAU=; b=lHgCBYXO49zZWQNxX+9w6RKQpsS9UJTCujfDSqrccBY6a8ph3yizmjO0vEDJugltuv 1S5KdKO03o9ERohNgA22SmMibpJ1FKLUpuSAZeqTTaw0A3jCV8JdTvTU/j4Y9O7WLeq2 HhjUdpupzPwJ+FEEj2t8B2/XTj9bhUndNltfXuVr68rr+SwE8T2QAFmf9qx4eu2RC0Rz 3/rhj4412PYnRwTBQpbWGNeOigZxtCYKQGb0xPGeZIoJ6m8NHIquI0Xj9emK+6upXwup LADv0iHH7LZhXKT9Jc1kvPF93eQB8nWjU08R98cw/lth6H+AIgehzguCq009ofN+JoaZ fNdQ== MIME-Version: 1.0 Received: by 10.152.113.199 with SMTP id ja7mr1683815lab.10.1342696285092; Thu, 19 Jul 2012 04:11:25 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Thu, 19 Jul 2012 04:11:25 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64040A3BC1@DEMUEXC006.nsn-intra.net> References: <5006C43A.2090509@ripe.net> <5006C613.1@ripe.net> <20120718.224808.231495970.mbj@tail-f.com> <5007B280.3060605@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64040A3BC1@DEMUEXC006.nsn-intra.net> Date: Thu, 19 Jul 2012 04:11:25 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlDj+NDC7/R4b+cndP8UtTpyeNt3hDkGUojednz8EYtDVxSqORtik5K4ASo/L01v7thdw7P Cc: netconf@ietf.org Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 11:10:34 -0000 On Thu, Jul 19, 2012 at 3:57 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: >> >> W.r.t. Netconf Lite: >> >> the WG obviously does not want a Netconf 2.0. The analysis of the >> >> discussion as well as the last direct response of WG members is > rather >> >> positive than being negative. WG members are in general against 2.0 > but >> >> most of them support 1.2 and don't have anything against N-L if the > WG >> >> does it. Only a few are against 2.0 or any other change. >> > >> > Mehmet then wrote: >> > >> > My understanding is that Netconf-Lite is not 1.2. >> > >> > Juergen's original proposal was a separate protocol, not even > NETCONF >> > 1.2, which I believe is what Mehmet is also suggesting. But this >> > seems to contradict what Bert wrote above. > > As a co-chair and contributor I differentiate between Netconf-Lite and > 1.2. IOW somebody who wants Netconf-Lite to be equally the same as 1.2, > needs to state this explicitly. > The description above is as difficult as the long discussion on the > maillist was. Different persons have seen different overlapping between > the acronyms 2.0, 1.2, 1.1 and N-L. > > At the end of the day we need to proceed. So I fully agree with and > support the advancement of 1.1. If the WG approves the charter proposal > we can do Netconf-Lite too. > > BTW: I assume we also need to care bullet (4) in section 2.2. of 6410. > http://www.ietf.org/mail-archive/web/netconf/current/msg07621.html > Does anybody know what this patent claims to cover? What part of NETCONF does Huawei claim to have invented? > Mehmet Andy From andy@yumaworks.com Thu Jul 19 07:56:44 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B211221F8715 for ; Thu, 19 Jul 2012 07:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSSIIm6NNxjE for ; Thu, 19 Jul 2012 07:56:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 094C921F8738 for ; Thu, 19 Jul 2012 07:56:42 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4124498lbb.31 for ; Thu, 19 Jul 2012 07:57:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=bwuwgjBE2DJU1UKbpyJ22S4dDmraXVO4mkViBhDYEnw=; b=ObFUjPeV4kGAxM1Wzqpn0fuvNNVPige4In8RzT2MwINduwclO9km4Y3l5ncqo2apX2 oEsuF3NZO3OwN2FPOZYGbIPZN1diN6qehRaoAUtvcAfh1KAGzC/ZG6XMevUGDafEXyHu c2KiJkQ2YsY/320+xqvJa8diYtGq+tfCrqU5M5mpoBJlD2ehb0biqJWI6KV1OXQGNSCh 3gu90yBtwU1/K5hHMZ5srhJxFzZYPFbLALeVPoseTZr0m+gZ0bezKTtUk0QwDLd/e25/ s1+22nH1mnVIiB5joyffKs+YgYStmACIrg6YIKW1kOkJ2a5fMoIjsC1GFFjK7/CnVhBG 0zJQ== MIME-Version: 1.0 Received: by 10.112.30.136 with SMTP id s8mr1374232lbh.51.1342709855071; Thu, 19 Jul 2012 07:57:35 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Thu, 19 Jul 2012 07:57:35 -0700 (PDT) X-Originating-IP: [75.84.168.164] Date: Thu, 19 Jul 2012 07:57:35 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmkzON0MU2fNdot/CKp/VkbjxEyxJxOpj/blkuuj/0tPAJb3JxZUeYxoXkaBKG0wdvFMVkF Subject: [Netconf] confirmed-commit bug in RFC 6241? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 14:56:44 -0000 Hi, Just wondering about some confirmed-commit text in 6241: 7.2, para 2: If a NETCONF server receives a request while processing a confirmed commit (Section 8.4), it MUST restore the configuration to its state before the confirmed commit was issued. Really? It doesn't say that this is only done if it is the session that issued the confirmed commit. It also is not correct if the parameter was provided in the commit that started (or continued) the confirmed commit procedure. I think we missed this edit in the 4741 -> 6241 rewrite. I also think 8.4.1 could be more clear that commits from other sessions that do not have the persist-id will be completed by the server, and are not rejected. They are subject to being rolled back of course (that is documented). Andy From bertietf@bwijnen.net Thu Jul 19 12:44:55 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A8621F8769; Thu, 19 Jul 2012 12:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.573 X-Spam-Level: X-Spam-Status: No, score=-99.573 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7noAk3WHULn; Thu, 19 Jul 2012 12:44:53 -0700 (PDT) Received: from relay59.tele2.vuurwerk.nl (relay59.tele2.vuurwerk.nl [62.250.3.59]) by ietfa.amsl.com (Postfix) with ESMTP id BC25821F8736; Thu, 19 Jul 2012 12:44:50 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1SrwfO-00016I-QX; Thu, 19 Jul 2012 21:45:42 +0200 Message-ID: <110BD9FD10C343A2BE7D237BBE18B754@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "IESG" Date: Thu, 19 Jul 2012 21:45:44 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Cc: Netconf Subject: [Netconf] advancement on standards track. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 19:44:55 -0000 RFC 6410, in particular section 2.2.m states: (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. So we wonder if that means that we need to investigate any "patent disclosures" or "patenet claims" against our RFCs. We are not lawyers... so ?? What if we believe the claims are justs bogus. For example, if the patent applications were filed (long) after the first internet-drafts describing the technology were posted? So I wonder, has rfc6410 created a situation where a company can block (certainly delay for a long time) the advancement on standards track by just filing a patent disclosure against some RFC ??? Bert Wijnen co-chair of NetConf WG From kwatsen@juniper.net Thu Jul 19 13:51:25 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C88421F865F for ; Thu, 19 Jul 2012 13:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAmOkl8FGvbo for ; Thu, 19 Jul 2012 13:51:24 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id AA07721F8652 for ; Thu, 19 Jul 2012 13:51:23 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUAhzfs4ysPRFvuCWtyde2aQr0Bx21tzl@postini.com; Thu, 19 Jul 2012 13:52:17 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 19 Jul 2012 13:50:01 -0700 From: Kent Watsen To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" Date: Thu, 19 Jul 2012 13:49:58 -0700 Thread-Topic: [Netconf] draft updated NETCONF WG charter Thread-Index: Ac1l8BBHWm5GpeMKTqyfcKW7s388Cg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:51:25 -0000 >> >> BTW: I assume we also need to care bullet (4) in section 2.2. of 6410. >> http://www.ietf.org/mail-archive/web/netconf/current/msg07621.html >> > >Does anybody know what this patent claims to cover? >What part of NETCONF does Huawei claim to have invented? The email linked to https://datatracker.ietf.org/ipr/1800/ which states that the patent is "CN200910176679 and the counterpart applications PCT/CN2010/075102, US 13/428659 and EP10818328.6". Being in the US, I googled the US number and found it here: http://www.freepatentsonline.com/y2012/0179795.html >From the "Background of the invention" section: "In the prior art, if the user modifies the configuration of the confirmed-commit operation, the candidate configuration database of the current confirmed-commit operation will be discarded, and the telecom device performs confirmed-commit operation again according to the configuration information resent by the user until the user's requirements are met. The method in the prior art requires the user to perform configuration again, with complicated operations and low efficiency. Moreover, the user commits a configuration of current confirmed-commit operation to be effect, and performs a next modification to the configuration, the current operation of the service will be impacted." Also note this from the IPR: "If any claim of any patent owned or controlled by Huawei or its Affiliates is essential on a technical ground to the specification adopted by IETF, Huawei on behalf of itself and its Affiliates hereby covenant not to assert any such claim against any party for making, using, selling, offering for sale or importing a product that implements the corresponding part of the specification. However, nothing herein shall preclude Huawei or any of its Affiliates from asserting the above mentioned patent claims against any party that asserts directly or indirectly a patent it owns or controls against Huawei and/or its Affiliates, or against any products of Huawei or its Affiliates either alone or in combination with other products. FRAND royalty-bearing licenses will be available to anyone who prefers that option." From bertietf@bwijnen.net Fri Jul 20 00:20:56 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2930921F853C for ; Fri, 20 Jul 2012 00:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gjUDNTyy4BG for ; Fri, 20 Jul 2012 00:20:55 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 40DC921F8526 for ; Fri, 20 Jul 2012 00:20:52 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Ss7Wt-0000vO-MG; Fri, 20 Jul 2012 09:21:40 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest23.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Ss7Wt-00066t-Hz; Fri, 20 Jul 2012 09:21:39 +0200 Message-ID: <50090703.6030004@bwijnen.net> Date: Fri, 20 Jul 2012 09:21:39 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120720 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd429be7ebbdae4403137a72ade500a0b4f Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 07:20:56 -0000 So (but I am not a lawyer) this seems to tell me that you can freely implement/use this technology as long as you do not assert any (any I guess means in any context, so also context outside netconf)patent claims against Huawei. Oh well... I guess that if 2 of our implementations/deployments are no holding any patent assertions against Huawei, then we have met the rfc6410 requirements, no? Bert On 7/19/12 10:49 PM, Kent Watsen wrote: > "If any claim of any patent owned or controlled by Huawei or its > Affiliates is essential on a technical ground to the specification adopted > by IETF, Huawei on behalf of itself and its Affiliates hereby covenant not > to assert any such claim against any party for making, using, selling, > offering for sale or importing a product that implements the corresponding > part of the specification. However, nothing herein shall preclude Huawei > or any of its Affiliates from asserting the above mentioned patent claims > against any party that asserts directly or indirectly a patent it owns or > controls against Huawei and/or its Affiliates, or against any products of > Huawei or its Affiliates either alone or in combination with other > products. > FRAND royalty-bearing licenses will be available to anyone who prefers > that option." From bertietf@bwijnen.net Fri Jul 20 02:49:22 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C05521F859F for ; Fri, 20 Jul 2012 02:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScbkdAJOGSAU for ; Fri, 20 Jul 2012 02:49:21 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 2444321F8575 for ; Fri, 20 Jul 2012 02:49:21 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Ss9qc-0004ty-M9 for netconf@ietf.org; Fri, 20 Jul 2012 11:50:13 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest23.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Ss9qb-00046F-JR for netconf@ietf.org; Fri, 20 Jul 2012 11:50:10 +0200 Message-ID: <500929D1.3070107@bwijnen.net> Date: Fri, 20 Jul 2012 11:50:09 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120720 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4b1ae5e6b312b40ebd7652718fdd5a1dd Subject: [Netconf] RFC4743 and RFC4744 (Netconf over SOAP and BEEP) to historic X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 09:49:22 -0000 Can't submit a rev 00 I-D at the moment. But since we have the "making RFC4743 and RFC4744 to Historic" topic as part of a possible revised WG charter on the agenda, I did quickly do an initial writeup, so people can see how we might approach this. I have it attached below. Bert ---------------------------------------------------------------------- netconf B. Wijnen Internet-Draft July 19, 2012 Obsoletes: 4743/4744 (if approved) Intended status: Informational Expires: January 20, 2013 RFC4743 and RFC4744 to Historic status draft-bwijnen-netconf-rfc4743-rfc4744-to-historic-00 Abstract This document moves RFC4743 (Using NETCONF over the Simple Object Access Protocol (SOAP)) and RFC4744 (Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)) to HISTORIC status to reflect the fact that those two documents have shown very little (if any) implementations and deployment. Furthermore, no-one in the NETCONF WG is nterested or volunteering to work on them anymore. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 20, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Wijnen Expires January 20, 2013 [Page 1] Internet-Draft RFC4743-RFC4744-historic July 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Normative References . . . . . . . . . . . . . . . . . . . 3 5.2. Informative References . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 Wijnen Expires January 20, 2013 [Page 2] Internet-Draft RFC4743-RFC4744-historic July 2012 1. Introduction This document moves RFC 4743 [RFC4743] and RFC 4744 [RFC4744] to HISTORIC status in accordance with RFC 2026 [RFC2026]. These have seen very little (if any) implementations or deployment, and none of the initial proponents are active in the NETCONF space anymorei. No- one (else) in the WG is interested or willing to pick up responsibility for these documents. Possibly changes might be needed for compatibility with NETCONF 1.1. In the WG nobody gave a positive response when asked who is using it or wants to keep it. 2. Acknowledgements Thanks to the original editors/authors of RFC4743 and RFC4744. At the time, these NETCONF transports seemed to be attractive. 3. IANA Considerations This memo includes no request to IANA. 4. Security Considerations This draft introduces no new security considerations. 5. References 5.1. Normative References [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006. [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006. 5.2. Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Wijnen Expires January 20, 2013 [Page 3] Internet-Draft RFC4743-RFC4744-historic July 2012 Author's Address Bert Wijnen Schagen 33 Linschoten, 3461 GL Netherlands Phone: +31 348-407-775 Email: bertietf@bwijnen.net Wijnen Expires January 20, 2013 [Page 4] From kwatsen@juniper.net Fri Jul 20 08:55:38 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE3121F861B for ; Fri, 20 Jul 2012 08:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dpcBQ6crtPC for ; Fri, 20 Jul 2012 08:55:37 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4521F8616 for ; Fri, 20 Jul 2012 08:55:36 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUAl/pflA56Sq6TpyHSqLIBSdRBMx+NE6@postini.com; Fri, 20 Jul 2012 08:56:33 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 20 Jul 2012 08:53:33 -0700 From: Kent Watsen To: "Bert Wijnen (IETF)" Date: Fri, 20 Jul 2012 08:53:34 -0700 Thread-Topic: [Netconf] draft updated NETCONF WG charter Thread-Index: Ac1mj9DwTBdlZDXGSu+41Ovp8uRx6g== Message-ID: In-Reply-To: <50090703.6030004@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft updated NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 15:55:38 -0000 AFAIK, that is correct (disclaimer: I'm also not a lawyer) Juniper also submits IPR claims for drafts, as IETF requests this of submitters (e.g. I directed my company to submit one for the Reverse SSH draft). In this case, Huawei didn't submit anything (at least, not yet), but they went ahead and filed the IPR, enabling the WG to consider incorporating their invention in a future update to NETCONF, which is pretty cool of them I think. Thanks, Kent On 7/20/12 3:21 AM, "Bert Wijnen (IETF)" wrote: >So (but I am not a lawyer) this seems to tell me that you can >freely implement/use this technology as long as you do not >assert any (any I guess means in any context, so also context outside >netconf)patent claims against Huawei. > >Oh well... I guess that if 2 of our implementations/deployments >are no holding any patent assertions against Huawei, then we have met >the rfc6410 requirements, no? > >Bert > >On 7/19/12 10:49 PM, Kent Watsen wrote: >> "If any claim of any patent owned or controlled by Huawei or its >> Affiliates is essential on a technical ground to the specification >>adopted >> by IETF, Huawei on behalf of itself and its Affiliates hereby covenant >>not >> to assert any such claim against any party for making, using, selling, >> offering for sale or importing a product that implements the >>corresponding >> part of the specification. However, nothing herein shall preclude Huawei >> or any of its Affiliates from asserting the above mentioned patent >>claims >> against any party that asserts directly or indirectly a patent it owns >>or >> controls against Huawei and/or its Affiliates, or against any products >>of >> Huawei or its Affiliates either alone or in combination with other >> products. >> FRAND royalty-bearing licenses will be available to anyone who prefers >> that option." From andy@yumaworks.com Fri Jul 27 05:53:17 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E32321F8667 for ; Fri, 27 Jul 2012 05:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4on50igKxw4g for ; Fri, 27 Jul 2012 05:53:17 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA68721F865A for ; Fri, 27 Jul 2012 05:53:16 -0700 (PDT) Received: by lagv3 with SMTP id v3so2155295lag.31 for ; Fri, 27 Jul 2012 05:53:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=0EK681mLnulLbyOHIikzQSAqKJq6QS5Zm26lEHv1mx4=; b=F4Ya+1MYgtLb6fsftPf4WSFLohMKo3asvC9HFfzyMXF0s6Ez3fEfWA1kamrv7UGNKE sPBTccNsdUBu+yyo7eJCEghij4DvkwBGOoILII2S84/MG2KB0ICStA5ccpNvxauCOYn6 dudgihmTIhF4kz2I0dSOsFwYAOweeb49QdA47ahDFPmYLTt+ZSzUO9Xw2LpmGZ1RvwnA l5DbrDRvmFWuAIIcSP1FczH6e4girBkOeiX95zcifFUCdigbtpSs35Xy8nVhnsFx3LyE VPnUInuB+HtLf/3pL+3CCoOyThjsBaWn6AorQPwaJ5UQJqcRFvkE8I5mhthgDERA/Izh f0Wg== MIME-Version: 1.0 Received: by 10.152.113.199 with SMTP id ja7mr2544793lab.10.1343393595744; Fri, 27 Jul 2012 05:53:15 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Fri, 27 Jul 2012 05:53:15 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: Date: Fri, 27 Jul 2012 05:53:15 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQntaeJuqdcDy5hTxCGJJ53oRPYIkFLdA1o+Gq1sPe8z+TBX4HwdymHDW/vI7tgC3yzkOpcP Subject: Re: [Netconf] confirmed-commit bug in RFC 6241? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 12:53:17 -0000 On Thu, Jul 19, 2012 at 7:57 AM, Andy Bierman wrote: > Hi, > > Just wondering about some confirmed-commit text in 6241: > > 7.2, para 2: > > If a NETCONF server receives a request while > processing a confirmed commit (Section 8.4), it MUST restore the > configuration to its state before the confirmed commit was issued. > I did not get any comments. I checked what yuma implements, and it is not this text. It implements the (IMO) correct behavior. RFC 6241, sec 7.2, paragraph 2: OLD: If a NETCONF server receives a request while processing a confirmed commit (Section 8.4), it MUST restore the configuration to its state before the confirmed commit was issued. NEW: If a NETCONF server receives a request while processing a confirmed commit (Section 8.4), it MUST restore the configuration to its state before the confirmed commit was issued, if the session being killed is the same session that initiated the current confirmed commit procedure, and the 'persist' parameter was not present in the operation input parameters. Are there any objections to posting this RFC Errata for RFC 6241? > Andy Andy From bertietf@bwijnen.net Fri Jul 27 06:01:13 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C3121F8692 for ; Fri, 27 Jul 2012 06:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kibet-YZL6ba for ; Fri, 27 Jul 2012 06:01:13 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id CE79421F8690 for ; Fri, 27 Jul 2012 06:01:12 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SukAI-0007ng-4b; Fri, 27 Jul 2012 15:01:11 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SukAH-0005Hi-LJ; Fri, 27 Jul 2012 15:01:09 +0200 Message-ID: <50129115.3000201@bwijnen.net> Date: Fri, 27 Jul 2012 15:01:09 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Andy Bierman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120727 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd458031555336ff027aae92a508e92f530 Cc: Netconf Subject: Re: [Netconf] confirmed-commit bug in RFC 6241? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 13:01:13 -0000 So Andy, your new text (to me at least) seems more of a piece of clarifying text being added. Good thing I believe, but I would not consider the current text a bug. Bert (speaking as a technical contributor) On 7/27/12 2:53 PM, Andy Bierman wrote: > On Thu, Jul 19, 2012 at 7:57 AM, Andy Bierman wrote: >> Hi, >> >> Just wondering about some confirmed-commit text in 6241: >> >> 7.2, para 2: >> >> If a NETCONF server receives a request while >> processing a confirmed commit (Section 8.4), it MUST restore the >> configuration to its state before the confirmed commit was issued. >> > > > I did not get any comments. > I checked what yuma implements, and it is not this text. > It implements the (IMO) correct behavior. > > RFC 6241, sec 7.2, paragraph 2: > OLD: > > If a NETCONF server receives a request while > processing a confirmed commit (Section 8.4), it MUST restore the > configuration to its state before the confirmed commit was issued. > > NEW: > > If a NETCONF server receives a request while > processing a confirmed commit (Section 8.4), it MUST restore the > configuration to its state before the confirmed commit was issued, > if the session being killed is the same session that initiated the > current confirmed commit procedure, and the 'persist' parameter > was not present in the operation input parameters. > > > Are there any objections to posting this RFC Errata for RFC 6241? > > >> Andy > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@yumaworks.com Fri Jul 27 06:32:32 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB0C21F8688 for ; Fri, 27 Jul 2012 06:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXYlu1szACss for ; Fri, 27 Jul 2012 06:32:31 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 58C6321F8652 for ; Fri, 27 Jul 2012 06:32:30 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2294613lbb.31 for ; Fri, 27 Jul 2012 06:32:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=boBXV4yHZWC2WaR97uerQCpxVQ3xzMis5/rUKNNFhrI=; b=UcL2tuj7bSkI4bU2oX3vc0KK3bgsqyYvULn7PMxIyu7IiJUJIgvLb7Y6YCYqNZqRxu 579QiXFpjmo1VyGs7nnszql9wftRPDvfQFXUlGntFVdl6uxcwpfFylqgQum/z9PeaAEl izxZ+dd39kuVAbySupO3amo+yvyzreZqfouHg4kJWul0p+O+ZG8A5HzYXCEqAbyq1RTx fz3iwgwtOYt9OhiX5sbe8bdBqBrSN+UemiCEHHsDulz86b0dyuKObpme1bdpVC9pILAX iJ71yjcHPIbSthrVt/BG7fSbnVpCh+6UZ9BW8KshHghiDXRoVC0R5pnMlW2lsne2K+Ch 4Zpw== MIME-Version: 1.0 Received: by 10.152.106.233 with SMTP id gx9mr2558784lab.48.1343395949980; Fri, 27 Jul 2012 06:32:29 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Fri, 27 Jul 2012 06:32:29 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <50129115.3000201@bwijnen.net> References: <50129115.3000201@bwijnen.net> Date: Fri, 27 Jul 2012 06:32:29 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQknqouURKQHqD9PwMYer29jN87H7gdafw7xm3+FeOTdeWINcJ2JAJDRYcyrqyL8LKayRiz9 Cc: Netconf Subject: Re: [Netconf] confirmed-commit bug in RFC 6241? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 13:32:32 -0000 The current text seems like a bug to me because it says that any session being killed will cause the confirmed commit to be terminated. Even if that session is being killed, the persist parameter allows other sessions to finish the CC. All the IETF WEB sites are down right now, so I can't find the confirmed-commit text that says this is how it works. This text in 4271 wasn't even correct because a session that is not involved in the CC does not affect it. Andy On Fri, Jul 27, 2012 at 6:01 AM, Bert Wijnen (IETF) wrote: > So Andy, your new text (to me at least) seems more of a > piece of clarifying text being added. Good thing I believe, > but I would not consider the current text a bug. > > Bert (speaking as a technical contributor) > > On 7/27/12 2:53 PM, Andy Bierman wrote: >> >> On Thu, Jul 19, 2012 at 7:57 AM, Andy Bierman wrote: >>> >>> Hi, >>> >>> Just wondering about some confirmed-commit text in 6241: >>> >>> 7.2, para 2: >>> >>> If a NETCONF server receives a request while >>> processing a confirmed commit (Section 8.4), it MUST restore the >>> configuration to its state before the confirmed commit was issued. >>> >> >> >> I did not get any comments. >> I checked what yuma implements, and it is not this text. >> It implements the (IMO) correct behavior. >> >> RFC 6241, sec 7.2, paragraph 2: >> OLD: >> >> If a NETCONF server receives a request while >> processing a confirmed commit (Section 8.4), it MUST restore the >> configuration to its state before the confirmed commit was >> issued. >> >> NEW: >> >> If a NETCONF server receives a request while >> processing a confirmed commit (Section 8.4), it MUST restore the >> configuration to its state before the confirmed commit was >> issued, >> if the session being killed is the same session that initiated >> the >> current confirmed commit procedure, and the 'persist' parameter >> was not present in the operation input parameters. >> >> >> Are there any objections to posting this RFC Errata for RFC 6241? >> >> >>> Andy >> >> >> >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > From bclaise@cisco.com Fri Jul 27 16:43:49 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEF521F8685; Fri, 27 Jul 2012 16:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMgmpn9tRTzD; Fri, 27 Jul 2012 16:43:47 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9A721F8682; Fri, 27 Jul 2012 16:43:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6RNhk7E014746; Fri, 27 Jul 2012 16:43:46 -0700 (PDT) Received: from [10.21.64.247] (sjc-vpn3-247.cisco.com [10.21.64.247]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6RNhkA2019072; Fri, 27 Jul 2012 16:43:46 -0700 (PDT) Message-ID: <501327B2.6040208@cisco.com> Date: Fri, 27 Jul 2012 16:43:46 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: attendees <84attendees@ietf.org>, NETCONF , NETMOD Working Group Content-Type: multipart/alternative; boundary="------------000101040303070403030704" Subject: [Netconf] Network Configuration Management with NETCONF and YANG Tutorial this Sunday X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 23:43:49 -0000 This is a multi-part message in MIME format. --------------000101040303070403030704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, The "NETCONF and YANG" tutorial was added late to the agenda. So if you registered early, maybe you missed this tutorial announcement. Hence this email: 1300-1450 Network Configuration Management with NETCONF and YANG Tutorial - Regency E Regards, Benoit. --------------000101040303070403030704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

The "NETCONF and YANG" tutorial was added late to the agenda.
So if you registered early, maybe you missed this tutorial announcement.
Hence this email:
1300-1450 Network Configuration Management with NETCONF and YANG Tutorial - Regency E

Regards, Benoit.

--------------000101040303070403030704-- From mbj@tail-f.com Sun Jul 29 14:59:37 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396B221F866E for ; Sun, 29 Jul 2012 14:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyP6FfpqRDt9 for ; Sun, 29 Jul 2012 14:59:36 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A8F0021F8666 for ; Sun, 29 Jul 2012 14:59:36 -0700 (PDT) Received: from localhost (unknown [130.129.21.151]) by mail.tail-f.com (Postfix) with ESMTPSA id 468211200D1E; Sun, 29 Jul 2012 23:59:35 +0200 (CEST) Date: Sun, 29 Jul 2012 16:55:53 +0200 (CEST) Message-Id: <20120729.165553.345360398.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] confirmed-commit bug in RFC 6241? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 21:59:37 -0000 Andy Bierman wrote: > RFC 6241, sec 7.2, paragraph 2: > OLD: > > If a NETCONF server receives a request while > processing a confirmed commit (Section 8.4), it MUST restore the > configuration to its state before the confirmed commit was issued. > > NEW: > > If a NETCONF server receives a request while > processing a confirmed commit (Section 8.4), it MUST restore the > configuration to its state before the confirmed commit was issued, > if the session being killed is the same session that initiated the > current confirmed commit procedure, and the 'persist' parameter > was not present in the operation input parameters. > > > Are there any objections to posting this RFC Errata for RFC 6241? No. I think this is a correct clarification. /martin From kwatsen@juniper.net Sun Jul 29 20:43:10 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C9021F8599 for ; Sun, 29 Jul 2012 20:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQPwxShne1ai for ; Sun, 29 Jul 2012 20:43:10 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id C2F3021F8582 for ; Sun, 29 Jul 2012 20:43:07 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUBYCyb5z5KnQsvRydfu9m2XDLpuvt1my@postini.com; Sun, 29 Jul 2012 20:43:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Sun, 29 Jul 2012 20:42:25 -0700 From: Kent Watsen To: Andy Bierman , Netconf Date: Sun, 29 Jul 2012 20:42:40 -0700 Thread-Topic: [Netconf] confirmed-commit bug in RFC 6241? Thread-Index: Ac1uBVWCQmAweZIpSQSDPmZojWDUmA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] confirmed-commit bug in RFC 6241? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 03:43:10 -0000 I like it. My only comment is grammatical - the last two commas caused me to have to rescan the text and therefore seem out of place. Here's the same text with the last two commas removed: If a NETCONF server receives a request while processing a confirmed commit (Section 8.4), it MUST restore the configuration to its state before the confirmed commit was issued if the session being killed is the same session that initiated the current confirmed commit procedure and the 'persist' parameter was not present in the operation input parameters. See you all tomorrow Kent On 7/27/12 8:53 AM, "Andy Bierman" wrote: >On Thu, Jul 19, 2012 at 7:57 AM, Andy Bierman wrote: >> Hi, >> >> Just wondering about some confirmed-commit text in 6241: >> >> 7.2, para 2: >> >> If a NETCONF server receives a request while >> processing a confirmed commit (Section 8.4), it MUST restore the >> configuration to its state before the confirmed commit was issued. >> > > >I did not get any comments. >I checked what yuma implements, and it is not this text. >It implements the (IMO) correct behavior. > >RFC 6241, sec 7.2, paragraph 2: >OLD: > > If a NETCONF server receives a request while > processing a confirmed commit (Section 8.4), it MUST restore the > configuration to its state before the confirmed commit was issued. > >NEW: > > If a NETCONF server receives a request while > processing a confirmed commit (Section 8.4), it MUST restore the > configuration to its state before the confirmed commit was issued, > if the session being killed is the same session that initiated the > current confirmed commit procedure, and the 'persist' parameter > was not present in the operation input parameters. > > >Are there any objections to posting this RFC Errata for RFC 6241? > > >> Andy > > >Andy >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Mon Jul 30 11:50:04 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0660321F85D4; Mon, 30 Jul 2012 11:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1hzU6rN8txE; Mon, 30 Jul 2012 11:50:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4E95621F85D1; Mon, 30 Jul 2012 11:50:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D8EB20BD4; Mon, 30 Jul 2012 20:50:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ohLl6jXJeJWh; Mon, 30 Jul 2012 20:50:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 124A920BDE; Mon, 30 Jul 2012 20:50:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8B41420FAD8C; Mon, 30 Jul 2012 20:50:00 +0200 (CEST) Date: Mon, 30 Jul 2012 20:50:00 +0200 From: Juergen Schoenwaelder To: attendees <84attendees@ietf.org>, NETCONF , NETMOD Working Group Message-ID: <20120730185000.GB76317@elstar.local> Mail-Followup-To: attendees <84attendees@ietf.org>, NETCONF , NETMOD Working Group References: <501327B2.6040208@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501327B2.6040208@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Netconf] Network Configuration Management with NETCONF and YANG Tutorial this Sunday X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:50:04 -0000 On Fri, Jul 27, 2012 at 04:43:46PM -0700, Benoit Claise wrote: > Dear all, > > The "NETCONF and YANG" tutorial was added late to the agenda. > So if you registered early, maybe you missed this tutorial announcement. > Hence this email: > 1300-1450 Network Configuration Management with NETCONF and YANG > Tutorial - Regency E > Since the slides are not on any IETF web pages yet, I have put them up for download here: http://cnds.eecs.jacobs-university.de/slides/2012-ietf-84-netconf-yang.pdf /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Mon Jul 30 12:12:40 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE1711E81BA for ; Mon, 30 Jul 2012 12:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqstvnTJq+dx for ; Mon, 30 Jul 2012 12:12:39 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DCB7011E81A4 for ; Mon, 30 Jul 2012 12:12:38 -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 q6UJCZqY031932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Jul 2012 21:12:35 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6UJCYJS014785 for ; Mon, 30 Jul 2012 21:12:34 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jul 2012 21:12:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 30 Jul 2012 21:12:33 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64041361A1@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need volunteers for the NomCom Thread-Index: Ac1uccmZ44cbj+LDTuSSbdGYcAbKLQAFW3/w From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Jul 2012 19:12:34.0833 (UTC) FILETIME=[46A2D810:01CD6E87] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1512 X-purgate-ID: 151667::1343675555-00002E58-63681EDF/0-0/0-0 Subject: [Netconf] FW: Need volunteers for the NomCom X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 19:12:40 -0000 DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogd2djaGFpcnMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOndnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQg Tm9tQ29tIENoYWlyDQpTZW50OiBTdW5kYXksIEp1bHkgMjksIDIwMTIgODoyMyBQTQ0KVG86IFdv cmtpbmcgR3JvdXAgQ2hhaXJzDQpTdWJqZWN0OiBOZWVkIHZvbHVudGVlcnMgZm9yIHRoZSBOb21D b20NCg0KV2UgYXJlIGN1cnJlbnRseSBsb29raW5nIGZvciB2b2x1bnRlZXJzIHRvIHNlcnZlIG9u IHRoZSAyMDEyLTIwMTMgTm9tQ29tLg0KQXMgeW91IGtub3csIHRoZSBzdWNjZXNzIG9mIHRoZSBO b21Db20gcHJvY2VzcyBkZXBlbmRzIGNydWNpYWxseSBvbiANCmhhdmluZyBhIGxhcmdlIHBvb2wg b2Ygdm9sdW50ZWVycyBmcm9tIHRocm91Z2hvdXQgdGhlIElFVEYgY29tbXVuaXR5LiANCkluIHBh cnRpY3VsYXIsIGl0IGlzIHZhbHVhYmxlIGZvciB0aGUgcG9vbCBvZiB2b2x1bnRlZXJzIHRvIGhh dmUgc3Ryb25nIA0KcmVwcmVzZW50YXRpb24gZnJvbSBhbGwgb2YgdGhlIHRlY2huaWNhbCBhcmVh cyB3aXRoaW4gdGhlIElFVEYuIA0KDQpJIHVuZGVyc3RhbmQgdGhhdCBub3QgYWxsIElFVEYgcGFy dGljaXBhbnRzIHJlYWQgdGhlIElFVEYgYW5ub3VuY2UgbGlzdCANCmZyZXF1ZW50bHkuIFRoZXJl Zm9yZSwgaWYgeW91IHdvdWxkIGJlIHdpbGxpbmcgdG8gaW5mb3JtIGFjdGl2ZSBwYXJ0aWNpcGFu dHMgDQppbiB5b3VyIHdvcmtpbmcgZ3JvdXBzIGFib3V0IHRoaXMgeWVhcidzIGNhbGwgZm9yIE5v bUNvbSB2b2x1bnRlZXJzLCBJIA0Kd291bGQgZ3JlYXRseSBhcHByZWNpYXRlIGl0LiANCg0KVGhl IE5vbUNvbSAyMDEyLTIwMTMgQ2FsbCBmb3IgVm9sdW50ZWVycyBpcyBvcGVuIHVudGlsIHRoaXMg U3VuZGF5LCANCkF1Z3VzdCA1LiBEZXRhaWxzIGNhbiBiZSBmb3VuZCBhdDogaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9hbm4vbm9tY29tLzQ5ODUxLw0KDQpUaGFuayB5b3UgZm9yIHlvdXIg aGVscCwNCi0gTWF0dCBMZXBpbnNraQ0KICBtbGVwaW5za2kuaWV0ZkBnbWFpbC5jb20NCiAgbm9t Y29tLWNoYWlyQGlldGYub3JnDQo= From kwatsen@juniper.net Tue Jul 31 13:48:07 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8DE21F86C3 for ; Tue, 31 Jul 2012 13:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1jVJkrFpUFD for ; Tue, 31 Jul 2012 13:48:07 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id F2C2F21F85AD for ; Tue, 31 Jul 2012 13:48:04 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUBhEhOJtk+nFgjbwp5F0VlopfGkBFew4@postini.com; Tue, 31 Jul 2012 13:48:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 31 Jul 2012 13:46:29 -0700 From: Kent Watsen To: "netconf@ietf.org" Date: Tue, 31 Jul 2012 13:46:29 -0700 Thread-Topic: regarding draft-badra-netconf-rfc5539bis-02 Thread-Index: Ac1vXY9rWwdpAf8wRnKBShQSIElQZg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Netconf] regarding draft-badra-netconf-rfc5539bis-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:48:08 -0000 Hi Badra, As noted in yesterday's meeting, per the intent of the new charter to deprecate BEEP, the "Security Considerations" section of this draft should probably remove it's reference BEEP as an active transport. Thanks, Kent From bertietf@bwijnen.net Tue Jul 31 15:08:54 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DE521F884F for ; Tue, 31 Jul 2012 15:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNV7EplwxFSI for ; Tue, 31 Jul 2012 15:08:53 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD0421F884E for ; Tue, 31 Jul 2012 15:08:53 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwKcU-0006D5-N8; Wed, 01 Aug 2012 00:08:52 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-53c6.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SwKcU-0006pY-1Z; Wed, 01 Aug 2012 00:08:50 +0200 Message-ID: <50185770.3060806@bwijnen.net> Date: Tue, 31 Jul 2012 15:08:48 -0700 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120731 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40b24d2a902302159812d9329c665f38f Cc: "netconf@ietf.org" Subject: Re: [Netconf] regarding draft-badra-netconf-rfc5539bis-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:08:54 -0000 At least, it is best to NOT have them as normative references. Informative might be OK. But could indeed also remove them. Bert On 7/31/12 1:46 PM, Kent Watsen wrote: > > Hi Badra, > > As noted in yesterday's meeting, per the intent of the new charter to > deprecate BEEP, the "Security Considerations" section of this draft should > probably remove it's reference BEEP as an active transport. > > Thanks, > Kent > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >