From mehmet.ersue@nsn.com Tue Dec 1 04:21:57 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FBD328C0EE for ; Tue, 1 Dec 2009 04:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7KHqbQDme2k for ; Tue, 1 Dec 2009 04:21:56 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id AEAA628C0F2 for ; Tue, 1 Dec 2009 04:21:55 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nB1CLeQT016133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2009 13:21:40 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nB1CLXEL017411; Tue, 1 Dec 2009 13:21:40 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 13:21:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7280.D57DD2D1" Date: Tue, 1 Dec 2009 13:21:39 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A642096BE@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A641A0CCB@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] IETF #76 NETCONF WG Session Draft minutes Thread-Index: AcprlxC720JW2T16SA6xK6qgAsNwiQG6VnkQ References: <80A0822C5E9A4440A5117C2F4CD36A641A0CCB@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 01 Dec 2009 12:21:40.0364 (UTC) FILETIME=[D5E86CC0:01CA7280] Subject: Re: [Netconf] IETF #76 NETCONF WG Session Draft minutes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 12:21:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7280.D57DD2D1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I uploaded the minutes for the NETCONF session in Hiroshima to the meeting material site. http://www.ietf.org/proceedings/09nov/minutes/netconf.txt =20 Mehmet=20 =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Sunday, November 22, 2009 6:13 PM To: netconf@ietf.org Subject: [Netconf] IETF #76 NETCONF WG Session Draft minutes =09 =09 Dear NETCONF WG,=20 attached are the draft minutes for the NETCONF session=20 at IETF #76.=20 Many thanks to Lada and Wes for taking the minutes and=20 Dan for scribing and channeling the jabber room!=20 Please review the draft minutes and let us know your=20 comments by November 30, 2009 EOB. Thanks.=20 <<091122_IETF76_NETCONF WG_Draft_Minutes.txt>>=20 Mehmet & Bert=20 ------_=_NextPart_001_01CA7280.D57DD2D1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF #76 NETCONF WG Session Draft minutes
Hi=20 All,
 
I uploaded the minutes for the NETCONF = session in=20 Hiroshima to the meeting material site.
http:/= /www.ietf.org/proceedings/09nov/minutes/netconf.txt
 
Mehmet=20
 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN -=20 DE/Munich)
Sent: Sunday, November 22, 2009 6:13 = PM
To:=20 netconf@ietf.org
Subject: [Netconf] IETF #76 NETCONF WG = Session=20 Draft minutes


Dear NETCONF WG,

attached are the draft minutes for = the NETCONF=20 session
at IETF #76. =

Many thanks to Lada and Wes for = taking the=20 minutes and
Dan for scribing = and=20 channeling the jabber room!

Please review the draft minutes and = let us know=20 your
comments by November 30, = 2009 EOB.=20 Thanks.

<<091122_IETF76_NETCONF=20 WG_Draft_Minutes.txt>>
Mehmet &=20 Bert =

------_=_NextPart_001_01CA7280.D57DD2D1-- From balazs.lengyel@ericsson.com Tue Dec 1 08:27:56 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911B73A672E; Tue, 1 Dec 2009 08:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.791 X-Spam-Level: X-Spam-Status: No, score=-4.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtWrv6kdhPfw; Tue, 1 Dec 2009 08:27:55 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2FA833A67A1; Tue, 1 Dec 2009 08:27:11 -0800 (PST) X-AuditID: c1b4fb3c-b7b08ae000000935-cd-4b1543b4c5f2 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 93.B7.02357.4B3451B4; Tue, 1 Dec 2009 17:26:28 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:26:18 +0100 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:26:17 +0100 Message-ID: <4B1543A9.2000407@ericsson.com> Date: Tue, 01 Dec 2009 17:26:17 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2009 16:26:17.0947 (UTC) FILETIME=[026DDAB0:01CA72A3] X-Brightmail-Tracker: AAAAAA== Cc: David Partain , netconf@ietf.org, NETMOD Working Group , "Kessens, David \(NSN - US/Atlanta\)" Subject: Re: [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:27:56 -0000 +1 for SHOULD
Balazs

On 11/20/09 19:32, Ersue, Mehmet (NSN - DE/Munich) wrote:
Consensus call: With-Defaults as SHOULD in 4741bis

Hi All,

in the NETCONF/NETMOD conference call we discussed the
handling of with-defaults in 4741bis document and the
YANG specification.

We had a rough consensus on having 'with-defaults' as
SHOULD to implement (see point 3 in the attached mail
from October 02, 2009), which is going to be added to
the 4741bis document if we have consensus.

We do not want to go through a re-run of all arguments
for and against. Since this conclusion has an impact
on both NETCONF 4741bis and the YANG specifications
the co-chairs of NETCONF and NETMOD WGs are keen of
having a final consensus call on that.

All on NETCONF and NETMOD WG maillists, please read
the attached mail of David Partain and respond to this
mail by December 1, 2009 EOB PT.
<<[netmod] Information from chair phone call on 24 September>>

If you agree with the conclusion having 'with-defaults'
as SHOULD to implement in 4741bis please state so.
If you disagree with this consensus, state your opinion too.

Thank you.

Bert & Mehmet 


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

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel@ericsson.com
From balazs.lengyel@ericsson.com Tue Dec 1 08:44:17 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46EA63A67A1 for ; Tue, 1 Dec 2009 08:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmZcI48R2ySv for ; Tue, 1 Dec 2009 08:44:16 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2FF483A63EB for ; Tue, 1 Dec 2009 08:44:15 -0800 (PST) X-AuditID: c1b4fb3e-b7b33ae0000045f9-3b-4b1547d6b26d Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 68.2E.17913.6D7451B4; Tue, 1 Dec 2009 17:44:06 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:44:06 +0100 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:43:44 +0100 Message-ID: <4B1547C0.8040201@ericsson.com> Date: Tue, 01 Dec 2009 17:43:44 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2009 16:43:45.0012 (UTC) FILETIME=[72874B40:01CA72A5] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] with-defaults basic mode configurable X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:44:17 -0000 Hello, During the last IETF the question was asked: Should the basic-mode of with-defaults be configurable? A number of implementations have it as configurable per session. The proposal is: The basic-mode of with-defaults is seen as configurable. This is a property of the specific NETCONF session. The current value can always be fetched as part of the with-defaults capability from the netconf-monitoring data module. How the value is set is left implementation specific, as this is not seen as an essential feature just a convenience item. No changes will be made to the with-defaults draft due to this issue. Balazs From balazs.lengyel@ericsson.com Tue Dec 1 08:46:12 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211543A6912 for ; Tue, 1 Dec 2009 08:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.885 X-Spam-Level: X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfbd0NEcQVhb for ; Tue, 1 Dec 2009 08:46:11 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F20623A680F for ; Tue, 1 Dec 2009 08:46:10 -0800 (PST) X-AuditID: c1b4fb3c-b7b08ae000000935-84-4b15483fad7f Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 81.79.02357.E38451B4; Tue, 1 Dec 2009 17:45:51 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:45:50 +0100 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:45:37 +0100 Message-ID: <4B154830.2030305@ericsson.com> Date: Tue, 01 Dec 2009 17:45:36 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2009 16:45:37.0183 (UTC) FILETIME=[B5633AF0:01CA72A5] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Uniform capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:46:12 -0000 Hello, Is there any rule that forces the NETCONF server to present the same set of capabilities to all sessions? Or is it possible to present different capabilities based on - the management user - the source of the session - operations during a session that change session settings - etc. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Tue Dec 1 08:48:38 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FEDF3A67C1 for ; Tue, 1 Dec 2009 08:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARwMGSG2gd31 for ; Tue, 1 Dec 2009 08:48:37 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 852143A67B6 for ; Tue, 1 Dec 2009 08:48:37 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-3d-4b1548dcde24 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 97.24.14961.CD8451B4; Tue, 1 Dec 2009 17:48:28 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:48:28 +0100 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:48:28 +0100 Message-ID: <4B1548DC.3060202@ericsson.com> Date: Tue, 01 Dec 2009 17:48:28 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2009 16:48:28.0359 (UTC) FILETIME=[1B6A9D70:01CA72A6] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:48:38 -0000 Hello, During the last IETF the question was asked: Should we make the explicit mode of with-defaults mandatory? The proposal is: Don't make it mandatory because - it requires a change in the underlying database - 1 bit of extra storage is cheap, BUT adapting an existing database and handling logic is EXPENSIVE - Makes adapting existing device to Netconf much more costly No changes will be made to the with-defaults draft due to this issue. Balazs From balazs.lengyel@ericsson.com Tue Dec 1 08:50:50 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B85228C0E9 for ; Tue, 1 Dec 2009 08:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-DzFjz8m881 for ; Tue, 1 Dec 2009 08:50:49 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 20C3C28C101 for ; Tue, 1 Dec 2009 08:50:48 -0800 (PST) X-AuditID: c1b4fb3e-b7b33ae0000045f9-ae-4b1549609aca Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 3C.6E.17913.069451B4; Tue, 1 Dec 2009 17:50:40 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:50:40 +0100 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:50:40 +0100 Message-ID: <4B154960.5000504@ericsson.com> Date: Tue, 01 Dec 2009 17:50:40 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2009 16:50:40.0622 (UTC) FILETIME=[6A4058E0:01CA72A6] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:50:50 -0000 Hello, During the last IETF the question was asked: Shall we use 3 features/capabilities instead of using parameters for the with-defaults capability? The proposal accepted by the room in Hiroshima is: No the current solution is more simple. No changes will be made to the with-defaults draft due to this issue. Balazs From balazs.lengyel@ericsson.com Tue Dec 1 08:52:57 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854A13A6A22 for ; Tue, 1 Dec 2009 08:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MMzRE1EeOxr for ; Tue, 1 Dec 2009 08:52:56 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8E89B3A6953 for ; Tue, 1 Dec 2009 08:52:56 -0800 (PST) X-AuditID: c1b4fb3c-b7b08ae000000935-f4-4b1549e07598 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 94.0A.02357.0E9451B4; Tue, 1 Dec 2009 17:52:48 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:52:27 +0100 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:52:27 +0100 Message-ID: <4B1549CB.8020200@ericsson.com> Date: Tue, 01 Dec 2009 17:52:27 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2009 16:52:27.0563 (UTC) FILETIME=[A9FE3FB0:01CA72A6] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Use 3 features/capabilities for with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:52:57 -0000 Hello, During the last IETF the question was asked: Shall we use 3 features/capabilities instead of using parameters for the with-defaults capability? The proposal accepted by the room in Hiroshima is: No the current solution is more simple. No changes will be made to the with-defaults draft due to this issue. Balazs PS. Sorry for the wrong title in the previous mail From balazs.lengyel@ericsson.com Tue Dec 1 08:55:23 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A27D3A68B9 for ; Tue, 1 Dec 2009 08:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvH9ZP8mc6oU for ; Tue, 1 Dec 2009 08:55:22 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 681443A692A for ; Tue, 1 Dec 2009 08:55:22 -0800 (PST) X-AuditID: c1b4fb3e-b7b33ae0000045f9-51-4b154a71571d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D8.9E.17913.17A451B4; Tue, 1 Dec 2009 17:55:13 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:55:12 +0100 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:55:12 +0100 Message-ID: <4B154A70.5050308@ericsson.com> Date: Tue, 01 Dec 2009 17:55:12 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2009 16:55:12.0564 (UTC) FILETIME=[0C576740:01CA72A7] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] with-defaults: change terminology X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:55:23 -0000 Hello, During the last IETF the question was asked about the with-defaults draft: Shall we speak of operations/operation replies instead of rpcs/rpc-replies? The proposal accepted by the room in Hiroshima is: No, other drafts/rfcs also speak about rpcs/rpc-replies, we don't want to introduce new terminology. No changes will be made to the with-defaults draft due to this issue. Balazs From balazs.lengyel@ericsson.com Tue Dec 1 09:00:24 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593393A692A for ; Tue, 1 Dec 2009 09:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvaTCVeIpIxq for ; Tue, 1 Dec 2009 09:00:23 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 57D0D3A6807 for ; Tue, 1 Dec 2009 09:00:23 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-e9-4b154b9f6ada Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 39.A4.14961.F9B451B4; Tue, 1 Dec 2009 18:00:15 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 18:00:14 +0100 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 18:00:14 +0100 Message-ID: <4B154B9E.4050407@ericsson.com> Date: Tue, 01 Dec 2009 18:00:14 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2009 17:00:14.0896 (UTC) FILETIME=[C08B9B00:01CA72A7] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] with-defaults: wait for YANG/4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:00:24 -0000 Hello, During the last IETF the question was asked about the with-defaults draft: Shall we wait for YANG and the 4741bis so we can make YANG normative? The proposal accepted by the room in Hiroshima is: Don't wait. with-defaults will try to keep it's YAM up to date with the YANG draft and 4741bis as long as possible, but it will not wait for the other two drafts to become rfcs. The with-defaults YAng Module will be informative only. Balazs From andy@netconfcentral.com Tue Dec 1 09:19:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AFA23A68E4 for ; Tue, 1 Dec 2009 09:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnoo18F65m5I for ; Tue, 1 Dec 2009 09:19:15 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 55BA33A68B8 for ; Tue, 1 Dec 2009 09:19:15 -0800 (PST) Received: (qmail 24519 invoked from network); 1 Dec 2009 17:19:05 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 01 Dec 2009 09:19:05 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: N8_AU3EVM1l.QMmDPFJHhrzSL5yLaTKPZHYZsf2C.tLC4Z54pAc5gbRk7xUmBeKpKaY.W.ucRFOE10fpA2Hlqoyh2DHkKkEtcc7KJViXZPwm7uSm9_NgRI9rAUqwca7HfOwHS6..ncbAQM_9Q1QygRqhQwFk32zw8qT.abkHhl9QQmW07_yvgZc6fg65nvLiQnUFqI94M45wXDwxWXvjPlUbZGSrXTPxllF1owiuYRUfc54RxmzAu_Iy9kCNAGnu X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B155020.7090406@netconfcentral.com> Date: Tue, 01 Dec 2009 09:19:28 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Balazs Lengyel References: <4B1547C0.8040201@ericsson.com> In-Reply-To: <4B1547C0.8040201@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf mailing list Subject: Re: [Netconf] with-defaults basic mode configurable X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:19:16 -0000 Balazs Lengyel wrote: > Hello, > During the last IETF the question was asked: > > Should the basic-mode of with-defaults be configurable? > A number of implementations have it as configurable per session. > > The proposal is: > > The basic-mode of with-defaults is seen as configurable. This is a > property of the specific NETCONF session. > The current value can always be fetched as part of the with-defaults > capability from the netconf-monitoring data module. Not quite right -- the data returned for a request is global data. All sessions see the exact same instances (modulo access control). Under no circumstances should a NETCONF server ever return session-specific values from the conceptual database. (Think 'SNMP context' and run away! :-) Instead, an RPC operation must be used, or a per-session data structure in the database. > How the value is set is left implementation specific, as this is not > seen as an essential feature just a convenience item. > No changes will be made to the with-defaults draft due to this issue. > > Balazs Andy From phil@juniper.net Tue Dec 1 09:35:20 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100093A6892 for ; Tue, 1 Dec 2009 09:35:20 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAboFu9CpIXH for ; Tue, 1 Dec 2009 09:35:19 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 262913A677E for ; Tue, 1 Dec 2009 09:35:19 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSxVTz0udnw4ERZhYVBFiMS7jbwwluR1b@postini.com; Tue, 01 Dec 2009 09:35:12 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 1 Dec 2009 09:31:14 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 09:31:13 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 09:31:13 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 09:31:12 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB1HVAj96656; Tue, 1 Dec 2009 09:31:11 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nB1HHX6F099597; Tue, 1 Dec 2009 17:17:34 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912011717.nB1HHX6F099597@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <4B154960.5000504@ericsson.com> Date: Tue, 1 Dec 2009 12:17:33 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2009 17:31:12.0070 (UTC) FILETIME=[1381DE60:01CA72AC] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf mailing list Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:35:20 -0000 Balazs Lengyel writes: >Shall we use 3 features/capabilities instead of using parameters for the with-defaults c >apability? >The proposal accepted by the room in Hiroshima is: >No the current solution is more simple. >No changes will be made to the with-defaults draft due to this issue. I can't follow the logic here, so maybe I'm missing something. I don't see why we would want to use a non-YANG construct (like parameters) when there is a perfect valid YANG construct (like features) that can be used. How can this possibly make sense? Should we use parameters since they are "simple" even though they are not YANG friendly? Are we trying to encouraging behaviors that can't be represented in the YANG module, or to encourage behaviors that can be modeled in YANG? Imagine that the MAMAGAMILLIAN working group came to the "YANG Doctors" mailing list proposing to do this? Would we encourage it? Are there any modeling rules in YANG that should be encouraged? Thanks, Phil From phil@juniper.net Tue Dec 1 09:38:11 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38D93A68A8 for ; Tue, 1 Dec 2009 09:38:11 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQNZftTml9bp for ; Tue, 1 Dec 2009 09:38:11 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 9E19F3A677E for ; Tue, 1 Dec 2009 09:38:10 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSxVUe92H9293njnvexCiQuG7MEtfdOEK@postini.com; Tue, 01 Dec 2009 09:38:03 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 1 Dec 2009 09:34:22 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 09:34:22 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 09:34:21 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 09:34:21 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB1HYLj98907; Tue, 1 Dec 2009 09:34:21 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nB1HKiLl099635; Tue, 1 Dec 2009 17:20:44 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912011720.nB1HKiLl099635@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <4B154B9E.4050407@ericsson.com> Date: Tue, 1 Dec 2009 12:20:44 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2009 17:34:21.0804 (UTC) FILETIME=[8498FAC0:01CA72AC] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf mailing list Subject: Re: [Netconf] with-defaults: wait for YANG/4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:38:11 -0000 Balazs Lengyel writes: >Shall we wait for YANG and the 4741bis so we can make YANG normative? >The proposal accepted by the room in Hiroshima is: >Don't wait. I vote to wait, to make the YANG normative and to help YANG take root by using it ourselves. The benefits of publishing w-d before YANG do not outweigh the benefits of having it use YANG and for the YANG module to be normative. Thanks, Phil From mehmet.ersue@nsn.com Tue Dec 1 09:47:35 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17A413A6359 for ; Tue, 1 Dec 2009 09:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0g1nHlBSIus for ; Tue, 1 Dec 2009 09:47:34 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id DEF243A67F2 for ; Tue, 1 Dec 2009 09:47:33 -0800 (PST) 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 nB1HlMoS003316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2009 18:47:22 +0100 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 nB1HlLht015492; Tue, 1 Dec 2009 18:47:21 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 18:47:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Dec 2009 18:47:14 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6420987E@DEMUEXC006.nsn-intra.net> In-Reply-To: <200912011720.nB1HKiLl099635@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] with-defaults: wait for YANG/4741bis Thread-Index: AcpyrQ0Iz4GtmbXTQw2JCLJE0AYC6AAAKjZA References: <4B154B9E.4050407@ericsson.com> <200912011720.nB1HKiLl099635@idle.juniper.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Phil Shafer" , "netconf mailing list" , "Balazs Lengyel" X-OriginalArrivalTime: 01 Dec 2009 17:47:15.0548 (UTC) FILETIME=[51C8F1C0:01CA72AE] Subject: Re: [Netconf] with-defaults: wait for YANG/4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:47:35 -0000 There are no obvious issues, like the inconsistencies we had=20 in the monitoring draft, which force us to use YANG immediately. This is the reason why we don't want to delay the W-D draft. Cheers, Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Phil Shafer > Sent: Tuesday, December 01, 2009 6:21 PM > To: Balazs Lengyel > Cc: netconf mailing list > Subject: Re: [Netconf] with-defaults: wait for YANG/4741bis >=20 > Balazs Lengyel writes: > >Shall we wait for YANG and the 4741bis so we can make YANG normative? > >The proposal accepted by the room in Hiroshima is: > >Don't wait. >=20 > I vote to wait, to make the YANG normative and to help YANG take > root by using it ourselves. The benefits of publishing w-d before > YANG do not outweigh the benefits of having it use YANG and for > the YANG module to be normative. >=20 > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From phil@juniper.net Tue Dec 1 09:54:27 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E494E28C119 for ; Tue, 1 Dec 2009 09:54:27 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X69UnFB7JNDl for ; Tue, 1 Dec 2009 09:54:27 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id D7AAE28C118 for ; Tue, 1 Dec 2009 09:54:26 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSxVYScYSreObRIn/8HWDOVmL/+O5Ob/v@postini.com; Tue, 01 Dec 2009 09:54:20 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 1 Dec 2009 09:51:44 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 09:51:43 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 09:51:43 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 09:51:40 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB1Hpdj09595; Tue, 1 Dec 2009 09:51:39 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nB1Hc3mK000142; Tue, 1 Dec 2009 17:38:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912011738.nB1Hc3mK000142@idle.juniper.net> To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6420987E@DEMUEXC006.nsn-intra.net> Date: Tue, 1 Dec 2009 12:38:03 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2009 17:51:40.0601 (UTC) FILETIME=[EFC4D290:01CA72AE] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf mailing list Subject: Re: [Netconf] with-defaults: wait for YANG/4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:54:28 -0000 "Ersue, Mehmet (NSN - DE/Munich)" writes: >There are no obvious issues, like the inconsistencies we had >in the monitoring draft, which force us to use YANG immediately. >This is the reason why we don't want to delay the W-D draft. What is the benefit of publishing now instead of waiting to use YANG, that hot new incredible network modeling language the NETMOD group has been working on? I hear it's the bee's knees. Thanks, Phil From andy@netconfcentral.com Tue Dec 1 10:00:07 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6CF28C12A for ; Tue, 1 Dec 2009 10:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2IfuESlPnH0 for ; Tue, 1 Dec 2009 10:00:06 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id AF4B228C127 for ; Tue, 1 Dec 2009 10:00:06 -0800 (PST) Received: (qmail 3335 invoked from network); 1 Dec 2009 17:59:56 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 01 Dec 2009 09:59:56 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 2wG_uPIVM1lPqBZoTMI3ZOJOG1ziJr5c.lqjt6bUB62hxdXolMVwY3mXE_YwX5v4SczGN.uUnI7.I.Db5KGwtHdZlV7DgIbfcGYYUUFDRwlermdHHVCbXA1Mzn6WTgfrOeuMMqlCeOrUPtr1w5FFNg2D4jxdbSwz0g5BKKjf2DEcTLSA1E1rmsD_8qPHdEaIdkhw12jkwMygpSM0seiPMdAtr.9_bircEqkrWTQ4x2OjsyzVATnDTzRy0iMb1JVj X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B155938.5020201@netconfcentral.com> Date: Tue, 01 Dec 2009 09:58:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912011717.nB1HHX6F099597@idle.juniper.net> In-Reply-To: <200912011717.nB1HHX6F099597@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf mailing list Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:00:07 -0000 Phil Shafer wrote: > Balazs Lengyel writes: >> Shall we use 3 features/capabilities instead of using parameters for the with-defaults c >> apability? >> The proposal accepted by the room in Hiroshima is: >> No the current solution is more simple. >> No changes will be made to the with-defaults draft due to this issue. > > I can't follow the logic here, so maybe I'm missing something. > > I don't see why we would want to use a non-YANG construct (like > parameters) when there is a perfect valid YANG construct (like > features) that can be used. How can this possibly make sense? > > Should we use parameters since they are "simple" even though they > are not YANG friendly? Are we trying to encouraging behaviors that > can't be represented in the YANG module, or to encourage behaviors > that can be modeled in YANG? > But features cannot distinguish the 'basic' behavior from the 'additional' behavior, supported by the server. > Imagine that the MAMAGAMILLIAN working group came to the "YANG > Doctors" mailing list proposing to do this? Would we encourage it? > Are there any modeling rules in YANG that should be encouraged? If it weren't for the 'basic' parameter, I would agree with you on W-D. I'm sure the YANG Doctors (like the MIB Doctors) would try to understand all the requirements of the author(s), and determine if features would be better than URI parameters, in this case. > > Thanks, > Phil Andy From mbj@tail-f.com Tue Dec 1 10:02:45 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0CD628C13D for ; Tue, 1 Dec 2009 10:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhYVBXaVXTmx for ; Tue, 1 Dec 2009 10:02:45 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 98DCE3A6A3A for ; Tue, 1 Dec 2009 10:02:31 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6AEA0616001; Tue, 1 Dec 2009 19:02:23 +0100 (CET) Date: Tue, 01 Dec 2009 19:02:21 +0100 (CET) Message-Id: <20091201.190221.114813746.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200912011717.nB1HHX6F099597@idle.juniper.net> References: <4B154960.5000504@ericsson.com> <200912011717.nB1HHX6F099597@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:02:46 -0000 Phil Shafer wrote: > Balazs Lengyel writes: > >Shall we use 3 features/capabilities instead of using parameters for the > >with-defaults c > >apability? > >The proposal accepted by the room in Hiroshima is: > >No the current solution is more simple. > >No changes will be made to the with-defaults draft due to this issue. > > I can't follow the logic here, so maybe I'm missing something. > > I don't see why we would want to use a non-YANG construct (like > parameters) when there is a perfect valid YANG construct (like > features) that can be used. So we have the 'basic' parameter, which is mandatory and can take three values, and we have the 'also-supported' parameter, which can take the extra one or two values, e.g.: ?basic=report-all&also-supported=trim,explicit How would you do this with YANG features? We would need parameterized features... /martin From phil@juniper.net Tue Dec 1 11:12:42 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C353A68F7 for ; Tue, 1 Dec 2009 11:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqjxrI-2blLi for ; Tue, 1 Dec 2009 11:12:40 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 1041928C116 for ; Tue, 1 Dec 2009 11:12:25 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSxVqj9ljxUa+dVP1vt8K4MFtQkTVxiEs@postini.com; Tue, 01 Dec 2009 11:12:18 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 1 Dec 2009 11:10:37 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 11:10:37 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 11:10:37 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 11:10:37 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB1JAaj61444; Tue, 1 Dec 2009 11:10:36 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nB1IuxE2000852; Tue, 1 Dec 2009 18:56:59 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912011856.nB1IuxE2000852@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091201.190221.114813746.mbj@tail-f.com> Date: Tue, 1 Dec 2009 13:56:59 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2009 19:10:37.0226 (UTC) FILETIME=[F70470A0:01CA72B9] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:12:43 -0000 Martin Bjorklund writes: >How would you do this with YANG features? "also supported" translates directly into features. Basic can be either three features (basic-trim means your basic behavior is trim) or as a config=false leafs that describes the current basic behavior. Hmmm... so this would be: feature report-all { ... } feature basic-report-all { if-feature report-all; description "Basic behavior is report-all"; ... } ... If you can't model this without parameters, does that mean YANG needs to add parameters? What would we be saying if another working group were coming to us with this scenario? Would we tell them that YANG can't do what they need? Thanks, Phil From andy@netconfcentral.com Tue Dec 1 11:42:31 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748343A6A44 for ; Tue, 1 Dec 2009 11:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNL5+s9rSxO2 for ; Tue, 1 Dec 2009 11:42:30 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 8AD1C28C11D for ; Tue, 1 Dec 2009 11:42:21 -0800 (PST) Received: (qmail 4972 invoked from network); 1 Dec 2009 19:42:11 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 01 Dec 2009 11:42:11 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: pKg_3J4VM1k5at55p_bAC4g0OHNjTgki.8nZo6GXXYA6h2.CH9EVmmAzRgGnAgpuwy0MAD0B77WeFE7IFNET6i2DAf2d99vRrPCHfUtSwGmKtsnx_.T37ebpKm5X9FP2iRdegmvNdr7MmE1NdonjpqE6DmY0Q6lI58xPz1StHSzvUohAtAmhmhjUUHOCucWTd1eo0CyV27_zHBhu0TjZ_h1ODPVzTfPxiowG4GC1GuKd5rjG0qT5tqID9wtpGupN X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1571AC.4090009@netconfcentral.com> Date: Tue, 01 Dec 2009 11:42:36 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912011856.nB1IuxE2000852@idle.juniper.net> In-Reply-To: <200912011856.nB1IuxE2000852@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:42:31 -0000 Phil Shafer wrote: > Martin Bjorklund writes: >> How would you do this with YANG features? > > "also supported" translates directly into features. Basic > can be either three features (basic-trim means your basic > behavior is trim) or as a config=false leafs that describes > the current basic behavior. Hmmm... so this would be: > > feature report-all { ... } > feature basic-report-all { > if-feature report-all; > description "Basic behavior is report-all"; > ... > } > ... > > If you can't model this without parameters, does that mean YANG > needs to add parameters? What would we be saying if another > working group were coming to us with this scenario? Would we > tell them that YANG can't do what they need? > Your solution doesn't really work because 'report-all' is not optional, and exactly 1 basic behavior must be reported by the server, not 0 to 3. This is not a YANG issue. The basic W-D server behavior is a NETCONF capability. I think the use of a capability URI with parameters is appropriate. > Thanks, > Phil Andy From mbj@tail-f.com Tue Dec 1 11:47:30 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A643A6A42 for ; Tue, 1 Dec 2009 11:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgjDdctnx1Fy for ; Tue, 1 Dec 2009 11:47:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4D58128C10F for ; Tue, 1 Dec 2009 11:47:11 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1206476C550; Tue, 1 Dec 2009 20:47:03 +0100 (CET) Date: Tue, 01 Dec 2009 20:47:02 +0100 (CET) Message-Id: <20091201.204702.125765787.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200912011856.nB1IuxE2000852@idle.juniper.net> References: <20091201.190221.114813746.mbj@tail-f.com> <200912011856.nB1IuxE2000852@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:47:30 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >How would you do this with YANG features? > > "also supported" translates directly into features. Yes. > Basic > can be either three features (basic-trim means your basic > behavior is trim) This could work, but you would still have to have text that says that exactly one of these basic-* features MUST be supported. > or as a config=false leafs that describes > the current basic behavior. Right; that is always an alternative to using features this way. > If you can't model this without parameters, does that mean YANG > needs to add parameters? What would we be saying if another > working group were coming to us with this scenario? Would we > tell them that YANG can't do what they need? No I don't think we should add parameters now. Let's put it on the wish list for yang v2. We need to put down the pen. /martin From j.schoenwaelder@jacobs-university.de Tue Dec 1 12:28:48 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DCC3A691B for ; Tue, 1 Dec 2009 12:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlYS8m5VOk7K for ; Tue, 1 Dec 2009 12:28:48 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B95F33A6A55 for ; Tue, 1 Dec 2009 12:28:47 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA31EC001A; Tue, 1 Dec 2009 21:28:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ND8yAfiFDJqL; Tue, 1 Dec 2009 21:28:39 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82422C0004; Tue, 1 Dec 2009 21:28:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 97508E3F81E; Tue, 1 Dec 2009 21:28:37 +0100 (CET) Date: Tue, 1 Dec 2009 21:28:37 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091201202837.GA5943@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <200912011856.nB1IuxE2000852@idle.juniper.net> <4B1571AC.4090009@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1571AC.4090009@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 01 Dec 2009 20:28:48 -0000 On Tue, Dec 01, 2009 at 08:42:36PM +0100, Andy Bierman wrote: > Phil Shafer wrote: > > Martin Bjorklund writes: > >> How would you do this with YANG features? > > > > "also supported" translates directly into features. Basic > > can be either three features (basic-trim means your basic > > behavior is trim) or as a config=false leafs that describes > > the current basic behavior. Hmmm... so this would be: > > > > feature report-all { ... } > > feature basic-report-all { > > if-feature report-all; > > description "Basic behavior is report-all"; > > ... > > } > > ... > > > > If you can't model this without parameters, does that mean YANG > > needs to add parameters? What would we be saying if another > > working group were coming to us with this scenario? Would we > > tell them that YANG can't do what they need? > > > > Your solution doesn't really work because 'report-all' > is not optional, and exactly 1 basic behavior must > be reported by the server, not 0 to 3. Can this not be spelled out in the 'description' statement? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Dec 1 12:33:33 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D813A67D1 for ; Tue, 1 Dec 2009 12:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95eXIDDeTeRc for ; Tue, 1 Dec 2009 12:33:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 030C23A68A0 for ; Tue, 1 Dec 2009 12:33:33 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BF20C001A; Tue, 1 Dec 2009 21:33:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t-OqH7HVjNEZ; Tue, 1 Dec 2009 21:33:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88718C0004; Tue, 1 Dec 2009 21:33:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 91FCEE3F889; Tue, 1 Dec 2009 21:33:23 +0100 (CET) Date: Tue, 1 Dec 2009 21:33:23 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20091201203323.GB5943@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf mailing list References: <4B154830.2030305@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B154830.2030305@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf mailing list Subject: Re: [Netconf] Uniform capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 01 Dec 2009 20:33:34 -0000 On Tue, Dec 01, 2009 at 05:45:36PM +0100, Balazs Lengyel wrote: > Is there any rule that forces the NETCONF server to present the same set > of capabilities to all sessions? Or is it possible to present different > capabilities based on > - the management user > - the source of the session > - operations during a session that change session settings > - etc. I have not checked but I hope the specs stay silent about this because we will end up debating what is "a NETCONF server"; so even if there would be text that says all sessions have to have the same capabilities, an implementation can simply claim every session gets a different server. And during software updates, this rightfully might be the case. /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@netconfcentral.com Tue Dec 1 13:00:27 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D1028C144 for ; Tue, 1 Dec 2009 13:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1aUMSeiJ0YC for ; Tue, 1 Dec 2009 13:00:26 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 6D61D28C146 for ; Tue, 1 Dec 2009 13:00:26 -0800 (PST) Received: (qmail 65283 invoked from network); 1 Dec 2009 21:00:16 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 01 Dec 2009 13:00:16 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: pDG9UzQVM1mwNnVPr6Y2W7Cb8r1AlK3ImJ3fGYdyquvDdCVAZUe8DFAHNApnCBMCrLzMrWvmPoL0.wz3CuOsKO.97kMNM5nBBgVZNh3JT_6oBQrOMMVZqyU8NSJPFe8mrQjqxCVHl.ekVEbHEKlGYg4uPdfpCsRC_0A4prRzs91FmfNSd7JCSEJ0ckPxy7btVzrAkNT0QyW_VxMJRG4F3smNBwVV0F2Fk0L6btRIDeh9AHvWE3MvKryyb0Viqmti X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1583FA.9050406@netconfcentral.com> Date: Tue, 01 Dec 2009 13:00:42 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer , "netconf@ietf.org" References: <200912011856.nB1IuxE2000852@idle.juniper.net> <4B1571AC.4090009@netconfcentral.com> <20091201202837.GA5943@elstar.local> In-Reply-To: <20091201202837.GA5943@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 21:00:27 -0000 Juergen Schoenwaelder wrote: > On Tue, Dec 01, 2009 at 08:42:36PM +0100, Andy Bierman wrote: >> Phil Shafer wrote: >>> Martin Bjorklund writes: >>>> How would you do this with YANG features? >>> "also supported" translates directly into features. Basic >>> can be either three features (basic-trim means your basic >>> behavior is trim) or as a config=false leafs that describes >>> the current basic behavior. Hmmm... so this would be: >>> >>> feature report-all { ... } >>> feature basic-report-all { >>> if-feature report-all; >>> description "Basic behavior is report-all"; >>> ... >>> } >>> ... >>> >>> If you can't model this without parameters, does that mean YANG >>> needs to add parameters? What would we be saying if another >>> working group were coming to us with this scenario? Would we >>> tell them that YANG can't do what they need? >>> >> Your solution doesn't really work because 'report-all' >> is not optional, and exactly 1 basic behavior must >> be reported by the server, not 0 to 3. > > Can this not be spelled out in the 'description' statement? > IMO, that is a hack and not how features were intended to be used. It takes 6 features to convey this simple information to the client. This is also a server behavior detail at the operation layer, not the content layer. The W-D server behavior is also not YANG-specific. The leaf added to the 3 RPC operations could apply to any content, not just YANG content. So waiting for YANG, and making the W-D extension YANG-only, would go against the agreed upon charter goals. > /js > Andy From j.schoenwaelder@jacobs-university.de Tue Dec 1 13:09:43 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7289B3A67D9 for ; Tue, 1 Dec 2009 13:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD0AP39kDmkh for ; Tue, 1 Dec 2009 13:09:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6ED303A679C for ; Tue, 1 Dec 2009 13:09:42 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C583AC001A; Tue, 1 Dec 2009 22:09:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XXZINsu6tDdH; Tue, 1 Dec 2009 22:09:34 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C4DCC0004; Tue, 1 Dec 2009 22:09:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 69834E3FAFE; Tue, 1 Dec 2009 22:09:33 +0100 (CET) Date: Tue, 1 Dec 2009 22:09:33 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091201210933.GB6054@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <200912011856.nB1IuxE2000852@idle.juniper.net> <4B1571AC.4090009@netconfcentral.com> <20091201202837.GA5943@elstar.local> <4B1583FA.9050406@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1583FA.9050406@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 01 Dec 2009 21:09:43 -0000 On Tue, Dec 01, 2009 at 10:00:42PM +0100, Andy Bierman wrote: > IMO, that is a hack and not how features were intended > to be used. It takes 6 features to convey this simple > information to the client. > > This is also a server behavior detail at the operation > layer, not the content layer. > > The W-D server behavior is also not YANG-specific. > The leaf added to the 3 RPC operations could > apply to any content, not just YANG content. So you make up an argument against using features in the 4741bis YANG module? > So waiting for YANG, and making the W-D extension YANG-only, > would go against the agreed upon charter goals. Now you are mixing threads. It helps us to stay focused. /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@netconfcentral.com Tue Dec 1 13:23:21 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686B63A68EE for ; Tue, 1 Dec 2009 13:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln2foL4wuvAr for ; Tue, 1 Dec 2009 13:23:20 -0800 (PST) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 8DB513A6809 for ; Tue, 1 Dec 2009 13:23:20 -0800 (PST) Received: (qmail 67841 invoked from network); 1 Dec 2009 21:23:10 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 01 Dec 2009 13:23:10 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: bmCkZwAVM1lYeh51gN8XmHTc5QfPxepI3pv_DOUxHO3y3gSflAnz8GIeYh2BPPoTk1ErxeBmuM7wv7IeRMepjl1gxf6dTUoapFBpfXsya9BMAKJADm5wae_VhMhjhnwZR4kKFRwTYAkHcp4oJ75XWK82S2AW178Ttd47nrsUPwX9P48M_wNEaZFxdrVgtD9ekbDAnoj7bKnyZsUeHLG5pt8a9wM1S1x1eRz3eaDH5X7c8sK.wpUdgDFkPTA0rxza X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B158957.4040709@netconfcentral.com> Date: Tue, 01 Dec 2009 13:23:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <200912011856.nB1IuxE2000852@idle.juniper.net> <4B1571AC.4090009@netconfcentral.com> <20091201202837.GA5943@elstar.local> <4B1583FA.9050406@netconfcentral.com> <20091201210933.GB6054@elstar.local> In-Reply-To: <20091201210933.GB6054@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 21:23:21 -0000 Juergen Schoenwaelder wrote: > On Tue, Dec 01, 2009 at 10:00:42PM +0100, Andy Bierman wrote: > >> IMO, that is a hack and not how features were intended >> to be used. It takes 6 features to convey this simple >> information to the client. >> >> This is also a server behavior detail at the operation >> layer, not the content layer. >> >> The W-D server behavior is also not YANG-specific. >> The leaf added to the 3 RPC operations could >> apply to any content, not just YANG content. > > So you make up an argument against using features in the 4741bis > YANG module? > Yes. I already implemented the YANG module. It simply augments the existing RPC functions. Nothing in ietf-netconf.yang needs to be touched. The correct server behavior is obtained with augment, not if-feature. The leaf is not even in the same namespace as ietf-netconf.yang. In this specific case, the solution that the WG has agreed upon all along is the correct one. >> So waiting for YANG, and making the W-D extension YANG-only, >> would go against the agreed upon charter goals. > > Now you are mixing threads. It helps us to stay focused. > No -- getting rid of the parameters and making them features would introduce a normative dependency on YANG. The advertisement of default processing behavior is not YANG-specific. > /js > Andy From j.schoenwaelder@jacobs-university.de Tue Dec 1 13:32:37 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381613A69C3 for ; Tue, 1 Dec 2009 13:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj7P7khUZyzJ for ; Tue, 1 Dec 2009 13:32:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 92D7F3A69CD for ; Tue, 1 Dec 2009 13:32:30 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA7B0C001A; Tue, 1 Dec 2009 22:32:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vQ74u12g-Ql9; Tue, 1 Dec 2009 22:32:22 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 044D2C0004; Tue, 1 Dec 2009 22:32:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 59A7AE3FB87; Tue, 1 Dec 2009 22:32:20 +0100 (CET) Date: Tue, 1 Dec 2009 22:32:20 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091201213220.GA6158@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <200912011856.nB1IuxE2000852@idle.juniper.net> <4B1571AC.4090009@netconfcentral.com> <20091201202837.GA5943@elstar.local> <4B1583FA.9050406@netconfcentral.com> <20091201210933.GB6054@elstar.local> <4B158957.4040709@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B158957.4040709@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 01 Dec 2009 21:32:37 -0000 On Tue, Dec 01, 2009 at 10:23:35PM +0100, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Tue, Dec 01, 2009 at 10:00:42PM +0100, Andy Bierman wrote: > > > >> IMO, that is a hack and not how features were intended > >> to be used. It takes 6 features to convey this simple > >> information to the client. > >> > >> This is also a server behavior detail at the operation > >> layer, not the content layer. > >> > >> The W-D server behavior is also not YANG-specific. > >> The leaf added to the 3 RPC operations could > >> apply to any content, not just YANG content. > > > > So you make up an argument against using features in the 4741bis > > YANG module? > > > > Yes. I already implemented the YANG module. > It simply augments the existing RPC functions. > Nothing in ietf-netconf.yang needs to be > touched. The correct server behavior > is obtained with augment, not if-feature. > The leaf is not even in the > same namespace as ietf-netconf.yang. I fail to see how this relates to the discussion at hand (which unfortunately carries a wrong subject line to do a mistake made by Balasz). > In this specific case, the solution that the > WG has agreed upon all along is the correct one. I leave the concensus reading to the chairs. > >> So waiting for YANG, and making the W-D extension YANG-only, > >> would go against the agreed upon charter goals. > > > > Now you are mixing threads. It helps us to stay focused. > > > > No -- getting rid of the parameters and making > them features would introduce a normative dependency on > YANG. The advertisement of default processing behavior > is not YANG-specific. I guess we talk about two very different things in a thread carrying a subject line that talks about a third issue. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mark.scott@ericsson.com Mon Nov 30 15:09:08 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67E73A697D for ; Mon, 30 Nov 2009 15:09:08 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvUixOMLiisy for ; Mon, 30 Nov 2009 15:09:07 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id D52B63A67E9 for ; Mon, 30 Nov 2009 15:09:07 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nAUMljgo007447 for ; Mon, 30 Nov 2009 17:08:43 -0600 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.120]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 30 Nov 2009 15:46:55 -0500 From: Mark Scott To: "netconf@ietf.org" Date: Mon, 30 Nov 2009 15:46:54 -0500 Thread-Topic: New Version Notification for draft-ietf-netconf-monitoring-10 Thread-Index: Acpx/ObvEWuDIaMESeSKl3cal/0lfgAAFd+0 Message-ID: <75C89D709A9670428520E1CF8DD1344F1F5F924843@EUSAACMS0714.eamcs.ericsson.se> References: <20091130203718.20A333A6988@core3.amsl.com> In-Reply-To: <20091130203718.20A333A6988@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Netconf] FW: New Version Notification for draft-ietf-netconf-monitoring-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 21:35:17 -0000 Hello, A new version (v10) of the NETCONF Monitoring Schema draft has been posted. Significant changes: - addresses comments received from WGLC on v09 - text previously in sections 2&3 are now in the normative YANG module, m= aking the module self descriptive - document title change per ML discussion - namespace change to align with YANG usage guidelines Refer to Change Log (Appendix A) for details and other changes. Please direct any comments on this version to the mailing list. cheers, Mark ________________________________________ From: IETF I-D Submission Tool [idsubmission@ietf.org] Sent: Monday, November 30, 2009 3:37 PM To: Mark Scott Cc: mbj@tail-f.com Subject: New Version Notification for draft-ietf-netconf-monitoring-10 A new version of I-D, draft-ietf-netconf-monitoring-10.txt has been success= fuly submitted by Mark Scott and posted to the IETF repository. Filename: draft-ietf-netconf-monitoring Revision: 10 Title: YANG Module for NETCONF Monitoring Creation_date: 2009-11-30 WG ID: netconf Number_of_pages: 36 Abstract: This document defines a NETCONF data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. The IETF Secretariat.= From phil@juniper.net Tue Dec 1 14:08:54 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4970E3A699C for ; Tue, 1 Dec 2009 14:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLeyesaqxXa7 for ; Tue, 1 Dec 2009 14:08:53 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 55E9D28C0FE for ; Tue, 1 Dec 2009 14:08:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSxWT6/YhibG4Hh8rkoX2bSQWGU2qYBv0@postini.com; Tue, 01 Dec 2009 14:08:46 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 1 Dec 2009 14:07:22 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 14:07:21 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 14:07:21 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 14:07:20 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB1M7Jj73113; Tue, 1 Dec 2009 14:07:20 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nB1Lrh7l002513; Tue, 1 Dec 2009 21:53:43 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912012153.nB1Lrh7l002513@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091201.204702.125765787.mbj@tail-f.com> Date: Tue, 1 Dec 2009 16:53:43 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2009 22:07:20.0824 (UTC) FILETIME=[A7411780:01CA72D2] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 22:08:54 -0000 Martin Bjorklund writes: >This could work, but you would still have to have text that says that >exactly one of these basic-* features MUST be supported. This is completely acceptable. >No I don't think we should add parameters now. Let's put it on the >wish list for yang v2. We need to put down the pen. Just to be clear, I do not want to add this feature, but use it to say that either what we have in YANG is good and useful and we should be using it, or it's not and we are not done with YANG. I am definitely not in the second camp. We should be solving this problem using the mechanisms defined in YANG, both to prove that what we have works and to not give a precedent to other WGs that will say YANG doesn't do what they need and they are going to use parameters or some other odd non-YANG-ish construct. Thanks, Phil From phil@juniper.net Tue Dec 1 14:14:30 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0E53A682C for ; Tue, 1 Dec 2009 14:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d-adUkZi4sp for ; Tue, 1 Dec 2009 14:14:29 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 426D23A699C for ; Tue, 1 Dec 2009 14:14:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSxWVPGdKpUMR5YxGPYFj21r+y0Y5jp+y@postini.com; Tue, 01 Dec 2009 14:14:22 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 1 Dec 2009 14:13:33 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 14:13:33 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 14:13:33 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 14:13:32 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB1MDWj77087; Tue, 1 Dec 2009 14:13:32 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nB1Lxtjs002605; Tue, 1 Dec 2009 21:59:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912012159.nB1Lxtjs002605@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B1583FA.9050406@netconfcentral.com> Date: Tue, 1 Dec 2009 16:59:55 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2009 22:13:32.0808 (UTC) FILETIME=[84F95880:01CA72D3] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: [Netconf] Use YANG features (was Re: Don't make with-defaults explicit mode mandatory ) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 22:14:30 -0000 Andy Bierman writes: >The W-D server behavior is also not YANG-specific. >The leaf added to the 3 RPC operations could >apply to any content, not just YANG content. W-D is not YANG-specific, but we are moving toward using YANG as a modeling language for NETCONF, and W-D should be using YANG for its data modeling needs. If YANG isn't good enough for us to use, we aren't done with it. And while W-D is not YANG specific, the expectation is that all future IETF work will use YANG, so using something that cannot be modeled in YANG works against the interest of both the NETCONF/NETMOD/IETF community and the pool of implementors that will be adding NETCONF and YANG to various devices. IMHO this is a no-brainer and I'm embarrassed that we didn't see it earlier. Thanks, Phil From Washam.Fan@huaweisymantec.com Tue Dec 1 22:46:01 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E4C3A67F7 for ; Tue, 1 Dec 2009 22:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiAzFt50C-gu for ; Tue, 1 Dec 2009 22:46:00 -0800 (PST) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 29CA23A67EE for ; Tue, 1 Dec 2009 22:46:00 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KU000IAGIS3TCA0@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 02 Dec 2009 14:45:40 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KU000DQRIS3F910@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 02 Dec 2009 14:45:39 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 02 Dec 2009 14:45:39 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 02 Dec 2009 14:45:39 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4B155020.7090406@netconfcentral.com> References: <4B1547C0.8040201@ericsson.com> <4B155020.7090406@netconfcentral.com> Cc: netconf mailing list Subject: Re: [Netconf] with-defaults basic mode configurable X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 06:46:01 -0000 Hi, My understanding is, basic-mode of defaults is for the server and would be automatically applied to all sessions handled by the server. If the client (via a session) want to retrieve in a different defaults mode, it should specify it explicitly along with the RPC. Are you guys saying the client can change the basic-mode for a session without impact on other sessions? How could we do that without no change to the current with-defaults I-D? Thanks, washam ----- Original Message ----- From: Andy Bierman Date: Wednesday, December 2, 2009 1:19 am Subject: Re: [Netconf] with-defaults basic mode configurable To: Balazs Lengyel Cc: netconf mailing list > Balazs Lengyel wrote: > > Hello, > > During the last IETF the question was asked: > > > > Should the basic-mode of with-defaults be configurable? > > A number of implementations have it as configurable per session. > > > > The proposal is: > > > > The basic-mode of with-defaults is seen as configurable. This is a > > property of the specific NETCONF session. > > The current value can always be fetched as part of the with-defaults > > capability from the netconf-monitoring data module. > > Not quite right -- the data returned for a request > is global data. All sessions see the exact same instances > (modulo access control). > > Under no circumstances should a NETCONF server > ever return session-specific values from > the conceptual database. (Think 'SNMP context' > and run away! :-) > > Instead, an RPC operation must be used, > or a per-session data structure in the database. > > > How the value is set is left implementation specific, as this is not > > seen as an essential feature just a convenience item. > > No changes will be made to the with-defaults draft due to this issue. > > > > Balazs > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From Washam.Fan@huaweisymantec.com Tue Dec 1 22:48:18 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2653A6882; Tue, 1 Dec 2009 22:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qD7J+nFoJjc2; Tue, 1 Dec 2009 22:48:18 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id DE17F3A67EE; Tue, 1 Dec 2009 22:48:17 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KU000F4RIVZ4490@hstga02-in.huaweisymantec.com>; Wed, 02 Dec 2009 14:48:00 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KU000DMZIVZFB10@hstml01-in.huaweisymantec.com>; Wed, 02 Dec 2009 14:47:59 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 02 Dec 2009 14:47:59 +0800 From: WashamFan To: netconf@ietf.org, NETMOD Working Group Message-id: Date: Wed, 02 Dec 2009 14:47:59 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B41B5E4198@zcarhxm2.corp.nortel.com> References: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> <200911301500.53656.david.partain@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41B5E4198@zcarhxm2.corp.nortel.com> Subject: Re: [Netconf] [netmod] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 06:48:18 -0000 +1 for SHOULD. washam > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of David Partain > Sent: Monday, November 30, 2009 9:01 AM > To: netconf@ietf.org; NETMOD Working Group > Subject: Re: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis > > Greetings, > > > If you agree with the conclusion having 'with-defaults' > > as SHOULD to implement in 4741bis please state so. > > +1 > > or... > > Yes, I agree with this conclusion. > > Cheers, > > David From lhotka@cesnet.cz Tue Dec 1 23:10:30 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FAEC3A67F7; Tue, 1 Dec 2009 23:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.422 X-Spam-Level: X-Spam-Status: No, score=0.422 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcHb3CP0YUmg; Tue, 1 Dec 2009 23:10:29 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4821B3A6A11; Tue, 1 Dec 2009 23:10:29 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B9B39D80095; Wed, 2 Dec 2009 08:10:21 +0100 (CET) From: Ladislav Lhotka To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 08:10:20 +0100 Message-ID: <1259737820.22111.50.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org, NETMOD Working Group Subject: Re: [Netconf] [netmod] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 07:10:30 -0000 Ersue, Mehmet (NSN - DE/Munich) píše v Pá 20. 11. 2009 v 19:32 +0100: > If you agree with the conclusion having 'with-defaults' > as SHOULD to implement in 4741bis please state so. +1 to SHOULD. Lada > If you disagree with this consensus, state your opinion too. > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bertietf@bwijnen.net Wed Dec 2 04:57:46 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD58E3A684A for ; Wed, 2 Dec 2009 04:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.732 X-Spam-Level: X-Spam-Status: No, score=-8.732 tagged_above=-999 required=5 tests=[AWL=1.867, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agw+6gQjG4-I for ; Wed, 2 Dec 2009 04:57:46 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id D8FF13A659B for ; Wed, 2 Dec 2009 04:57:45 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NFols-0002YZ-Nd; Wed, 02 Dec 2009 13:57:28 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id AFCE02F593; Wed, 2 Dec 2009 13:57:28 +0100 (CET) Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NFols-0003ft-K9; Wed, 02 Dec 2009 13:57:28 +0100 Message-ID: <4B166438.2020403@bwijnen.net> Date: Wed, 02 Dec 2009 13:57:28 +0100 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <200912011856.nB1IuxE2000852@idle.juniper.net> <4B1571AC.4090009@netconfcentral.com> <20091201202837.GA5943@elstar.local> <4B1583FA.9050406@netconfcentral.com> <20091201210933.GB6054@elstar.local> <4B158957.4040709@netconfcentral.com> <20091201213220.GA6158@elstar.local> In-Reply-To: <20091201213220.GA6158@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4d913bf3cc0856a568de28530997d20d1 Subject: [Netconf] Use 3 features/capabilities for with-defaults [was: Re: Don't make with-defaults explicit mode mandatory] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 12:57:46 -0000 See below for explanation. It would be good if people could use the PROPER subject line to express their opinion for consensus forming! -------- Original Message -------- Subject: Re: [Netconf] Don't make with-defaults explicit mode mandatory Date: Tue, 1 Dec 2009 22:32:20 +0100 From: Juergen Schoenwaelder Reply-To: Juergen Schoenwaelder To: Andy Bierman CC: netconf@ietf.org Juergen Schoenwaelder wrote: > >> In this specific case, the solution that the >> WG has agreed upon all along is the correct one. >> > > I leave the concensus reading to the chairs. > > And we are following the discussions. Now I think, this IS indeed the incorrect subject line. The one we want to use is this one: ------ Original Message -------- Subject: [Netconf] Use 3 features/capabilities for with-defaults Date: Tue, 01 Dec 2009 17:52:27 +0100 From: Balazs Lengyel To: netconf mailing list Hello, During the last IETF the question was asked: Shall we use 3 features/capabilities instead of using parameters for the with-defaults capability? The proposal accepted by the room in Hiroshima is: No the current solution is more simple. No changes will be made to the with-defaults draft due to this issue. Balazs PS. Sorry for the wrong title in the previous mail From mehmet.ersue@nsn.com Wed Dec 2 05:50:40 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9693A6AC6 for ; Wed, 2 Dec 2009 05:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iadcn7P4cnny for ; Wed, 2 Dec 2009 05:50:38 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D2A563A6AC2 for ; Wed, 2 Dec 2009 05:50:37 -0800 (PST) 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 nB2DoMg3011951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2009 14:50:22 +0100 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 nB2DoK2T002579; Wed, 2 Dec 2009 14:50:21 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 14:50:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7356.6094DDB7" Date: Wed, 2 Dec 2009 14:50:15 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64209B4B@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: FW: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis Thread-Index: AcpzVmA3HjkT9g8zTNSmwcAOqi7saw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf mailing list" X-OriginalArrivalTime: 02 Dec 2009 13:50:16.0606 (UTC) FILETIME=[610C53E0:01CA7356] Subject: Re: [Netconf] FW: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 13:50:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7356.6094DDB7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, WG LC for this consensus call has ended.=20 The WG co-chairs have come to the conclusion that we do have a rough consensus (in fact we saw only one objection) that RFC4741bis will state that with-defaults SHOULD be implemented. Bert and Mehmet ------------------------------------------------------ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Friday, November 20, 2009 7:33 PM To: netconf@ietf.org; NETMOD Working Group Cc: David Partain; Kessens, David (NSN - US/Atlanta) Subject: [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis Hi All,=20 in the NETCONF/NETMOD conference call we discussed the=20 handling of with-defaults in 4741bis document and the=20 YANG specification.=20 We had a rough consensus on having 'with-defaults' as=20 SHOULD to implement (see point 3 in the attached mail=20 from October 02, 2009), which is going to be added to=20 the 4741bis document if we have consensus.=20 We do not want to go through a re-run of all arguments=20 for and against. Since this conclusion has an impact=20 on both NETCONF 4741bis and the YANG specifications=20 the co-chairs of NETCONF and NETMOD WGs are keen of=20 having a final consensus call on that.=20 All on NETCONF and NETMOD WG maillists, please read=20 the attached mail of David Partain and respond to this=20 mail by December 1, 2009 EOB PT.=20 <<[netmod] Information from chair phone call on 24 September>>=20 If you agree with the conclusion having 'with-defaults'=20 as SHOULD to implement in 4741bis please state so.=20 If you disagree with this consensus, state your opinion too.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_001_01CA7356.6094DDB7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: FW: [netmod] Consensus call: With-Defaults as SHOULD in = 4741bis

Dear NETCONF WG,

WG LC for this consensus call has = ended.

The WG co-chairs have come to the = conclusion that we do have a rough consensus
(in fact we saw only one objection) = that RFC4741bis will state that with-defaults SHOULD be = implemented.

Bert and Mehmet

------------------------------------------------------
From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of ext Ersue, Mehmet = (NSN - DE/Munich)
Sent: Friday, November 20, 2009 7:33 PM
To: netconf@ietf.org; NETMOD Working Group
Cc: David Partain; Kessens, David (NSN - US/Atlanta)
Subject: [Netconf] Consensus call: With-Defaults as = SHOULD in 4741bis
Hi All,
in the NETCONF/NETMOD conference = call we discussed the
handling of with-defaults in 4741bis = document and the
YANG specification.
We had a rough consensus on = having 'with-defaults' as
SHOULD to implement (see point 3 in = the attached mail
from October 02, 2009), which is = going to be added to
the 4741bis document if we have = consensus.
We do not want to go through a = re-run of all arguments
for and against. Since this = conclusion has an impact
on both NETCONF 4741bis and the YANG = specifications
the co-chairs of NETCONF and NETMOD = WGs are keen of
having a final consensus call on = that.=20
All on NETCONF and NETMOD WG = maillists, please read
the attached mail of David Partain = and respond to this
mail by December 1, 2009 EOB = PT.
<<[netmod] = Information from chair phone call on 24 September>>=20
If you agree with the conclusion = having 'with-defaults'
as SHOULD to implement in 4741bis = please state so.
If you disagree with this = consensus, state your opinion too. =
Thank you.
Bert & Mehmet

------_=_NextPart_001_01CA7356.6094DDB7-- From balazs.lengyel@ericsson.com Wed Dec 2 06:21:41 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3110428C1E8 for ; Wed, 2 Dec 2009 06:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.158 X-Spam-Level: X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLbWnepa77hs for ; Wed, 2 Dec 2009 06:21:40 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0F48028C1CF for ; Wed, 2 Dec 2009 06:21:39 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-cb-4b1677eac0ee Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 3E.A5.14961.AE7761B4; Wed, 2 Dec 2009 15:21:30 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 15:21:30 +0100 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 15:21:09 +0100 Message-ID: <4B1677D4.50301@ericsson.com> Date: Wed, 02 Dec 2009 15:21:08 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: Phil Shafer References: <200912011738.nB1Hc3mK000142@idle.juniper.net> In-Reply-To: <200912011738.nB1Hc3mK000142@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2009 14:21:09.0322 (UTC) FILETIME=[B15A5AA0:01CA735A] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] with-defaults: wait for YANG/4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 14:21:41 -0000 Advantages: - Some people could implement with-defaults earlier. - Clarify some defaults related issues earlier. Balazs On 12/01/09 18:38, Phil Shafer wrote: > "Ersue, Mehmet (NSN - DE/Munich)" writes: > >> There are no obvious issues, like the inconsistencies we had >> in the monitoring draft, which force us to use YANG immediately. >> This is the reason why we don't want to delay the W-D draft. >> > What is the benefit of publishing now instead of waiting to use > YANG, that hot new incredible network modeling language the NETMOD > group has been working on? I hear it's the bee's knees. > > Thanks, > Phil > > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From mehmet.ersue@nsn.com Wed Dec 2 11:23:26 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D3D3A6AC8 for ; Wed, 2 Dec 2009 11:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbnbLkuhqZX2 for ; Wed, 2 Dec 2009 11:23:25 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 8AC7B3A6978 for ; Wed, 2 Dec 2009 11:23:22 -0800 (PST) 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 nB2JNB2i028280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2009 20:23:11 +0100 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 nB2JNB2n018808; Wed, 2 Dec 2009 20:23:11 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 20:23:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Dec 2009 20:23:09 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64209CD6@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-netconf-monitoring-10 Thread-Index: AcpM8tHJxxCBJN7QSL2T+SkMdEFmTwAABoPAASNfCEAIgLwuQA== References: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com> <80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 02 Dec 2009 19:23:05.0180 (UTC) FILETIME=[DF3EE9C0:01CA7384] Subject: [Netconf] WGLC for draft-ietf-netconf-monitoring-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:23:26 -0000 Dear NETCONF WG,=20 =20 we think the draft Mark submitted solves the issues=20 raised on the maillist recently.=20 This is just to be sure the WG has the chance for a=20 final review and approves the document before it goes=20 to AD review. This WGLC ends on Dec 16, 2009. The document is intended to go for standards track.=20 http://tools.ietf.org/html/draft-ietf-netconf-monitoring-10 Mehmet From andy@netconfcentral.com Wed Dec 2 12:14:32 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C4F3A689B for ; Wed, 2 Dec 2009 12:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOmCP8i0OP3E for ; Wed, 2 Dec 2009 12:14:30 -0800 (PST) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 247F93A6403 for ; Wed, 2 Dec 2009 12:14:30 -0800 (PST) Received: (qmail 79379 invoked from network); 2 Dec 2009 20:14:19 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 02 Dec 2009 12:14:19 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: U1pfqZgVM1l14BN4FnIQobYna8IQN.DEtke6WdesuKOokS9byOMHT.Gm0PS6Bd.Y1F31.L5JTyIfaP050yC4EnXoxhvP0PsnNonInMT5FIf8UhNngJbR6pQeSHYQ6ErM9oVMA0Bz03dSdSPQqjcw3adH5doHsnktBWOPaZVg2dSX35SdNv02JqE5e39p9ntfxKg3YNa7iK2gdLTI4z1z28eOUH9jYeUKt8GBC4j2OuLPWZ8EFeT4WfHJtVrgaybuL6rpiMYOa8W_A4pgRwh0TwBHpzbMVoPatBzWIgECNzZr3fKnZU3BeJnHDWYfl.9GcZH3JXZuNBVUXjniNun1JIDXfy6izuogvFEPIVXrd.P4k.hZfn3RZw1ProHqhXMT6WgwuCE59A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B16CA42.6080505@netconfcentral.com> Date: Wed, 02 Dec 2009 12:12:50 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Ersue, Mehmet \(NSN - DE/Munich\)" References: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com> <80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64209CD6@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64209CD6@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-monitoring-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 20:14:32 -0000 Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > we think the draft Mark submitted solves the issues > raised on the maillist recently. > > This is just to be sure the WG has the chance for a > final review and approves the document before it goes > to AD review. This WGLC ends on Dec 16, 2009. > > The document is intended to go for standards track. > http://tools.ietf.org/html/draft-ietf-netconf-monitoring-10 > There sure were a lot of changes from -09 to -10: // old: ietf-netconf-state (2009-06-16) ietf-netconf-state.yang // new: ietf-netconf-monitoring (2009-11-20) ietf-netconf-monitoring.yang M module M namespace M contact M description D revision '2009-06-16' A revision '2009-11-20' M identity transport M description M identity netconf-ssh M reference M identity netconf-soap-over-beep M reference M identity netconf-soap-over-https M reference M identity netconf-beep M reference M identity netconf-tls M reference M identity xsd M reference M identity rng M reference M identity yang M reference M identity yin M reference M identity rnc M reference D typedef SessionId A typedef session-id D grouping NETCONFDatastoreType D grouping CommonCounters A grouping netconf-datastore-type A grouping common-counters M container netconf-state A description 'The /netconf-state s...' M container capabilities M description M child node order M container datastores M list datastore M container name M choice datastore M case running M child node order M case candidate M child node order M case startup M child node order M container locks M description D grouping LockInfo A grouping lock-info D choice lockType A choice lock-type M container schemas M list schema M leaf identifier M description M leaf version M description M leaf format M description M leaf namespace M description M leaf-list location M description M container sessions M description M list session M key from 'sessionId' to 'session-id' A description 'Unique identifier fo...' D leaf sessionId M leaf transport M mandatory from 'false' to 'true' A description 'Identifies the trans...' M leaf username A description 'If present, the user...' D leaf sourceHost D leaf loginTime D leaf inRpcs D leaf inBadRpcs D leaf outRpcErrors D leaf outNotifications A leaf session-id A leaf source-host A leaf login-time A leaf in-rpcs A leaf in-bad-rpcs A leaf out-rpc-errors A leaf out-notifications M container statistics D leaf netconfStartTime D leaf inBadHellos D leaf inSessions D leaf droppedSessions D leaf inRpcs D leaf inBadRpcs D leaf outRpcErrors D leaf outNotifications A leaf netconf-start-time A leaf in-bad-hellos A leaf in-sessions A leaf dropped-sessions A leaf in-rpcs A leaf in-bad-rpcs A leaf out-rpc-errors A leaf out-notifications M rpc get-schema A description 'This operation is us...' M container input M leaf identifier A description 'Identifier for the s...' M leaf version M mandatory from 'true' to 'false' A description 'Version of the schem...' M leaf format M mandatory from 'true' to 'false' A description 'The data modeling la...' M container output M child node order Is the WG done making gratuitous name changes to every possible identifier in the document? I hope so. So camelCase is out and dashes are in? IMO, this does not help readability. The preference for all-lowercase-and-dashes is rather subjective. > Mehmet Andy From j.schoenwaelder@jacobs-university.de Wed Dec 2 15:42:50 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60ED3A690F for ; Wed, 2 Dec 2009 15:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLCfRJeZxcML for ; Wed, 2 Dec 2009 15:42:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B325D3A68D9 for ; Wed, 2 Dec 2009 15:42:49 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94109C0037; Thu, 3 Dec 2009 00:42:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3Y1ignEZH8We; Thu, 3 Dec 2009 00:42:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84CB9C000E; Thu, 3 Dec 2009 00:42:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CCDDDE423DE; Thu, 3 Dec 2009 00:42:39 +0100 (CET) Date: Thu, 3 Dec 2009 00:42:39 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091202234239.GE8055@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com> <80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64209CD6@DEMUEXC006.nsn-intra.net> <4B16CA42.6080505@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B16CA42.6080505@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WGLC for draft-ietf-netconf-monitoring-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 02 Dec 2009 23:42:50 -0000 On Wed, Dec 02, 2009 at 09:12:50PM +0100, Andy Bierman wrote: > So camelCase is out and dashes are in? yes > IMO, this does not help readability. > The preference for all-lowercase-and-dashes is rather subjective. The real value of a common coding style in software projects is consistency across groups of programmers, not so much the format itself. I believe the same applies to YANG artefacts. /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@netconfcentral.com Thu Dec 3 12:53:36 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73E7828C1CA for ; Thu, 3 Dec 2009 12:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gD0rcYphkm7 for ; Thu, 3 Dec 2009 12:53:35 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id C01B028C198 for ; Thu, 3 Dec 2009 12:53:35 -0800 (PST) Received: (qmail 25747 invoked from network); 3 Dec 2009 20:53:21 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 03 Dec 2009 12:53:21 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: bxWch94VM1kP3oVwdm9JrigWZXFxiomfH95R0kLwQR.5yUEVf5rfyJuAZoVLhhGC2IT1wE0UmqoMPiuiayr4LvjCIf9h2T_nSaap_vInXwqYuH1jjtgt0ZCtNrDAJ0Fo5owCKkvLRA6mDLfee4UMgp8.q73lba1FlNypVVkhVyy_oWUIw0HZXFbMRyYg99ng.wDFbmB4IGrA9k6k6OlnS_ASXtCdCvMtp1hdIWCX3nvHsFYC31g3lVCwhyoynQvqlZseKJ_J6mRwx.NoZd_Urm.wpkd8abfmWPGgLbzPS.Uq.JWdkMkgzXaN4GlztkxV5MI4loNoXmFZM.7ZUn3r2slUx.8aQUozN_PGI5WR4I5nlfrgaNfR2QbqT6L3LSXwiFdWd8.eMU8aJpt897IW3.vVOuxoOyCmTrjqHXe9z1RLwrR56xAybAdKhdhyX5MxSWo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B18256B.8070905@netconfcentral.com> Date: Thu, 03 Dec 2009 12:54:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912012159.nB1Lxtjs002605@idle.juniper.net> In-Reply-To: <200912012159.nB1Lxtjs002605@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Use YANG features (was Re: Don't make with-defaults explicit mode mandatory ) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 20:53:36 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The W-D server behavior is also not YANG-specific. >> The leaf added to the 3 RPC operations could >> apply to any content, not just YANG content. > > W-D is not YANG-specific, but we are moving toward using YANG as a > modeling language for NETCONF, and W-D should be using YANG for its > data modeling needs. If YANG isn't good enough for us to use, we > aren't done with it. > > And while W-D is not YANG specific, the expectation is that all > future IETF work will use YANG, so using something that cannot be > modeled in YANG works against the interest of both the NETCONF/NETMOD/IETF > community and the pool of implementors that will be adding NETCONF > and YANG to various devices. > > IMHO this is a no-brainer and I'm embarrassed that we didn't see > it earlier. > Using YANG correctly means different things to everybody. Having some familiarity with MIBs, my first instinct was to use a data model, not a hacked-up capability URI. But people want this info in the , so a few simple read-only leafs in the ietf-netconf-monitoring module is not going to work. IMO, your proposal is a misuse of YANG feature-stmt. The appropriate YANG usage (if any) would be to define a protocol operation (rpc-stmt or data-def-stmt), not content. The message is not part of the NETCONF content layer. We should maintain proper protocol layering. BTW, the 'with-defaults' feature in the ietf-with-defaults.yang is pointless. The module capability itself already conveys that information. Advertising the module, but not the feature, makes no sense at all. I'm embarrassed I didn't realize that from the start. > Thanks, > Phil > Andy From phil@juniper.net Fri Dec 4 08:57:03 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C6D3A688E for ; Fri, 4 Dec 2009 08:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6Iu8cOCWMnE for ; Fri, 4 Dec 2009 08:57:02 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 5CA093A684A for ; Fri, 4 Dec 2009 08:57:02 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSxk/UprkpFKH1c0B31cDjTtRmlfUG1Vo@postini.com; Fri, 04 Dec 2009 08:56:54 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Fri, 4 Dec 2009 08:48:39 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 08:48:39 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 08:48:39 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 08:48:38 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB4Gmbj76641; Fri, 4 Dec 2009 08:48:38 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nB4GYvqV038133; Fri, 4 Dec 2009 16:34:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912041634.nB4GYvqV038133@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <4B1677D4.50301@ericsson.com> Date: Fri, 4 Dec 2009 11:34:57 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Dec 2009 16:48:38.0727 (UTC) FILETIME=[A0D5E570:01CA7501] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf mailing list Subject: Re: [Netconf] with-defaults: wait for YANG/4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 16:57:03 -0000 Balazs Lengyel writes: >Advantages: >- Some people could implement with-defaults earlier. >- Clarify some defaults related issues earlier. I don't see either of these as important, let alone sufficiently important to have w-d avoid use of YANG as normative. Implementors can always (and have always) implement the draft, and publicatio of w-d will do little to clarify the defaults related issues. Thanks, Phil From mehmet.ersue@nsn.com Fri Dec 4 09:37:36 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F783A68A5 for ; Fri, 4 Dec 2009 09:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiPqeAfJFKWX for ; Fri, 4 Dec 2009 09:37:36 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 57D9E3A69F1 for ; Fri, 4 Dec 2009 09:37:27 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nB4HbF3U017712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2009 18:37:15 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nB4HbF81007077; Fri, 4 Dec 2009 18:37:15 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 18:37:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Dec 2009 18:37:14 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6424226D@DEMUEXC006.nsn-intra.net> In-Reply-To: <200912041634.nB4GYvqV038133@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] with-defaults: wait for YANG/4741bis Thread-Index: Acp1AslkC+0lcvkcTRykX0kIBXUO/gABNH8g References: <4B1677D4.50301@ericsson.com> <200912041634.nB4GYvqV038133@idle.juniper.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Phil Shafer" X-OriginalArrivalTime: 04 Dec 2009 17:37:15.0547 (UTC) FILETIME=[6B654EB0:01CA7508] Cc: netconf mailing list Subject: Re: [Netconf] with-defaults: wait for YANG/4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 17:37:36 -0000 Phil, WG chairs and the WG are usually keen of keeping=20 their deadlines and avoiding unnecessary delay. If there are no obvious issues, like the=20 inconsistencies we had in the monitoring draft,=20 then there is no sufficient reason to delay the=20 W-D draft. Mehmet =20 > -----Original Message----- > From: ext Phil Shafer [mailto:phil@juniper.net]=20 > Sent: Friday, December 04, 2009 5:35 PM > To: Balazs Lengyel > Cc: Ersue, Mehmet (NSN - DE/Munich); netconf mailing list > Subject: Re: [Netconf] with-defaults: wait for YANG/4741bis=20 >=20 > Balazs Lengyel writes: > >Advantages: > >- Some people could implement with-defaults earlier. > >- Clarify some defaults related issues earlier. >=20 > I don't see either of these as important, let alone sufficiently > important to have w-d avoid use of YANG as normative. Implementors > can always (and have always) implement the draft, and publicatio > of w-d will do little to clarify the defaults related issues. >=20 > Thanks, > Phil >=20 From phil@juniper.net Fri Dec 4 09:57:55 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F413A6A3F for ; Fri, 4 Dec 2009 09:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wt5TSfO44lz for ; Fri, 4 Dec 2009 09:57:54 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 79B3E3A6A3E for ; Fri, 4 Dec 2009 09:57:54 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSxlNl9Gv+76bsCabATu2z5sqTRYTxddn@postini.com; Fri, 04 Dec 2009 09:57:46 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Fri, 4 Dec 2009 09:53:47 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 09:53:47 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 09:53:46 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 09:53:46 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB4Hrkj05231; Fri, 4 Dec 2009 09:53:46 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nB4He5vO038933; Fri, 4 Dec 2009 17:40:06 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912041740.nB4He5vO038933@idle.juniper.net> To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6424226D@DEMUEXC006.nsn-intra.net> Date: Fri, 4 Dec 2009 12:40:05 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Dec 2009 17:53:46.0836 (UTC) FILETIME=[BA400140:01CA750A] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf mailing list Subject: Re: [Netconf] with-defaults: wait for YANG/4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 17:57:55 -0000 "Ersue, Mehmet (NSN - DE/Munich)" writes: >If there are no obvious issues, like the >inconsistencies we had in the monitoring draft, >then there is no sufficient reason to delay the >W-D draft. I guess I'm surprised there's not more interest in making the YANG module normative. It's a minor point for the draft, but a bigger one for the NETCONF/YANG effort. But as the lone voice, I'll drop it. Thanks, Phil From j.schoenwaelder@jacobs-university.de Fri Dec 4 10:51:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6074A3A6A49 for ; Fri, 4 Dec 2009 10:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEIhOwhpwpFP for ; Fri, 4 Dec 2009 10:51:15 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8E8AF3A686C for ; Fri, 4 Dec 2009 10:51:15 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A50E2C0015; Fri, 4 Dec 2009 19:51:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SFgKPGV241Wd; Fri, 4 Dec 2009 19:51:05 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96DB2C0012; Fri, 4 Dec 2009 19:51:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3CF38E46E09; Fri, 4 Dec 2009 19:51:03 +0100 (CET) Date: Fri, 4 Dec 2009 19:51:03 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20091204185103.GA1297@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Phil Shafer , netconf mailing list References: <4B1677D4.50301@ericsson.com> <200912041634.nB4GYvqV038133@idle.juniper.net> <80A0822C5E9A4440A5117C2F4CD36A6424226D@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6424226D@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf mailing list Subject: Re: [Netconf] with-defaults: wait for YANG/4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:51:16 -0000 On Fri, Dec 04, 2009 at 06:37:14PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > WG chairs and the WG are usually keen of keeping > their deadlines and avoiding unnecessary delay. > > If there are no obvious issues, like the > inconsistencies we had in the monitoring draft, > then there is no sufficient reason to delay the > W-D draft. Both documents are in last call and I am going to read them both. I do not see the timing issue but then I do not have customers that can't work with NETCONF because of W-D not yet having an RFC number and a stable namespace. /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@netconfcentral.com Sat Dec 5 11:15:14 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD553A677D for ; Sat, 5 Dec 2009 11:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLhVAaUBgxlU for ; Sat, 5 Dec 2009 11:15:13 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id A73983A6870 for ; Sat, 5 Dec 2009 11:15:13 -0800 (PST) Received: (qmail 4544 invoked from network); 5 Dec 2009 19:15:02 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 05 Dec 2009 11:15:02 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: YEdXtb0VM1knaUtbimOYTL7pvkE1nbfk.0FYYrods0UU3JAlqCWT.1nTZu4EgLS48_9koI9ySs7a4Sx2IWfywp.Oj6jaJLhIMj3Qfv9nTo4zX6QIzeSWh0Jsm36CF1EFz8pbCcyMEi0SWHtxFM93rRrDf9nNVOuI9dh30qafhQXSKkc.41qk4UMcqItH61bN_7ZCs5w_m3NKHHS9Bie31HEALUXqjffZJ7EMsOoYAoZ_.ou8f4rMnF9lTPwsFqJJ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1AB133.6050605@netconfcentral.com> Date: Sat, 05 Dec 2009 11:14:59 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis: issue 7: keys in filter output X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 19:15:14 -0000 Hi, Issue: should keys be returned in and filter requests? Resolution: yes sec 6.2.5, para 2, add new bullet 4 NEW: o If any sibling nodes of the selection node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they SHOULD also be included in the filter output. --------------------------------------------------------------------------- sec 8.9.5.1., add new para 2 The XPath result for the select expression MUST be a node-set. Each node in the node-set MUST correspond to a node in underlying data model. In order to properly identify each node, the following encoding rules are defined: o All ancestor nodes of the result node MUST be encoded first, so the element returned in the reply contains only fully-specified sub-trees, according to the underlying data model. o If any sibling or ancestor nodes of the result node are needed identify a particular instance within a conceptual data strucure, then these nodes SHOULD also be encoded in the response. -------------------------------------------------------------------------------- Please comment on these proposed changes before 2009-12-12. Andy From mbj@tail-f.com Mon Dec 7 06:09:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A63128C152 for ; Mon, 7 Dec 2009 06:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj4q39pPlf9B for ; Mon, 7 Dec 2009 06:09:15 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8F67228C18E for ; Mon, 7 Dec 2009 06:09:15 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7957B76C685; Mon, 7 Dec 2009 15:09:04 +0100 (CET) Date: Mon, 07 Dec 2009 15:09:04 +0100 (CET) Message-Id: <20091207.150904.16456819.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1AB133.6050605@netconfcentral.com> References: <4B1AB133.6050605@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 7: keys in filter output X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 14:09:16 -0000 Andy Bierman wrote: > Hi, > > Issue: should keys be returned in and > filter requests? > > Resolution: yes > > sec 6.2.5, para 2, add new bullet 4 > > NEW: > > o If any sibling nodes of the selection node are instance identifier > components for a conceptual data structure (e.g., list key leaf), > then they SHOULD also be included in the filter output. Ok, but I think the SHOULD should be a MAY. 4741 states as motivation: The agent does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. In order to add keys, data-model-specific knowledge is necessary. > sec 8.9.5.1., add new para 2 > > The XPath result for the select expression MUST be a node-set. > Each node in the node-set MUST correspond to a node in > underlying data model. In order to properly identify > each node, the following encoding rules are defined: > > o All ancestor nodes of the result node MUST be encoded > first, so the element returned in the reply > contains only fully-specified sub-trees, according > to the underlying data model. Ok. > o If any sibling or ancestor nodes of the result node are needed > identify a particular instance within a conceptual data strucure, > then these nodes SHOULD also be encoded in the response. Ok, but I think the SHOULD should be a MUST. XPath is different from subtree filtering in this regard - in subtree filtering it is trivial for a client that understands the data model to ask for the keys, but in XPath it is not. /martin From andy@netconfcentral.com Mon Dec 7 06:40:05 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92BE53A6A44 for ; Mon, 7 Dec 2009 06:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f01Rjj6Nj2GP for ; Mon, 7 Dec 2009 06:40:04 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id D6C3C3A6832 for ; Mon, 7 Dec 2009 06:40:04 -0800 (PST) Received: (qmail 17915 invoked from network); 7 Dec 2009 14:39:52 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 07 Dec 2009 06:39:52 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: _B2Ad8sVM1mWJGgnIx9nKIQMCfbG8tesGHmaSk10ePKiS0daCGvvPjbsyFqmckpG3Oht3wVY4aveQWnZFztF8BEWWEj9m88_2NMfZZz.lKkqhjiRX_ERHrBt_TYiOstNasHwtqJB9FSXKyiccuiDU001dl5204cB6FUwJ7gbxb5PHMHkY4Z1PWfxhpCc.DqMUrNGOF0ilqcOuWpJwlqaqkVW7lrrYyahUYBFn9H1pHtoNTQAfAjAM7F_D9X6vOOTHiZAjqZwya09L2OfKk_GWP3MrFGv9iMKWDOk2QXnfitsVKBAYO_1gqk5cE80ww-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D13AA.4000606@netconfcentral.com> Date: Mon, 07 Dec 2009 06:39:38 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1AB133.6050605@netconfcentral.com> <20091207.150904.16456819.mbj@tail-f.com> In-Reply-To: <20091207.150904.16456819.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 7: keys in filter output X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 14:40:05 -0000 Martin Bjorklund wrote: all your changes are fine with me Andy > Andy Bierman wrote: >> Hi, >> >> Issue: should keys be returned in and >> filter requests? >> >> Resolution: yes >> >> sec 6.2.5, para 2, add new bullet 4 >> >> NEW: >> >> o If any sibling nodes of the selection node are instance identifier >> components for a conceptual data structure (e.g., list key leaf), >> then they SHOULD also be included in the filter output. > > Ok, but I think the SHOULD should be a MAY. 4741 states as > motivation: > > The agent does not need to utilize any data-model- > specific semantics during processing, allowing for simple and > centralized implementation strategies. > > In order to add keys, data-model-specific knowledge is necessary. > >> sec 8.9.5.1., add new para 2 >> >> The XPath result for the select expression MUST be a node-set. >> Each node in the node-set MUST correspond to a node in >> underlying data model. In order to properly identify >> each node, the following encoding rules are defined: >> >> o All ancestor nodes of the result node MUST be encoded >> first, so the element returned in the reply >> contains only fully-specified sub-trees, according >> to the underlying data model. > > Ok. > >> o If any sibling or ancestor nodes of the result node are needed >> identify a particular instance within a conceptual data strucure, >> then these nodes SHOULD also be encoded in the response. > > Ok, but I think the SHOULD should be a MUST. XPath is different from > subtree filtering in this regard - in subtree filtering it is trivial > for a client that understands the data model to ask for the keys, but > in XPath it is not. > > > /martin > From andy@netconfcentral.com Mon Dec 7 12:24:56 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F303A67A5 for ; Mon, 7 Dec 2009 12:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCH9oozapFld for ; Mon, 7 Dec 2009 12:24:55 -0800 (PST) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id ABD0C3A692F for ; Mon, 7 Dec 2009 12:24:55 -0800 (PST) Received: (qmail 78887 invoked from network); 7 Dec 2009 20:24:44 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 07 Dec 2009 12:24:44 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: zpFKYrEVM1nRMyY.HjYmTvXdU5x4Yik5Vf_Mkevfo_X90Vv_FSVZqRQrvKBDNOrlgvQ.7JDrEMh042QfYG4g6i8RNfD4Uja69qVUjsfJDLoBacSD6mu8Le2xF6F78PNiGPd3leCbfy0bs5fl1kbGbRJEefrQXG2HS5LyKC.uZKyifGmVkMs2ea4Ga6bJMX037Sn5GssyVBQNeKRESbzmWbZ85mO2JURGDfSy9y05tyGg7DLEwdPeO1UByNkeF3MW X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D647C.205@netconfcentral.com> Date: Mon, 07 Dec 2009 12:24:28 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis, issue 11, duplicate operations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 20:24:56 -0000 Hi, The resolution for this issue at the IETF meeting was that the YANG draft should specify any requirements for multiple operations on the same data node, if it wants. This behavior is not deterministic within the NETCONF protocol. The following 4741bis text is proposed to resolve this issue: OLD: (none) NEW: sec. 7.2, Description, new para 4: If the operation contains multiple sub-operations which apply to the same conceptual node in the underlying data model, then the result of the operation is undefined (i.e., outside the scope of the NETCONF protocol). Andy From andy@netconfcentral.com Mon Dec 7 13:04:19 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ABD228C1B7 for ; Mon, 7 Dec 2009 13:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-5HCiulisCk for ; Mon, 7 Dec 2009 13:04:18 -0800 (PST) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 899CF3A68BB for ; Mon, 7 Dec 2009 13:04:18 -0800 (PST) Received: (qmail 42953 invoked from network); 7 Dec 2009 21:04:06 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 07 Dec 2009 13:04:05 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: JyBFNycVM1m3tE8LwKfoDlEzpQ5L_kIs59DOWpZLn4UJxRSbF7nZElwtlhr90yWqrlzvxMhmW6VlUZGt37NjhqJOX3ZqT4qMr98KyVHFS4NuYXXkSUgNj8UL7GUc0HqlVa5LybRq4kO6EOH0pZEcRG1GO2h4bCJYfirLpeUxqwzI_aLYzZePSU7saGEzW4qLN3OKcdOJx5w1y.k37G6gmUT_UJYReT3rOhGTDogZXE2qV9V3QR6dZGp9q5dyRc76 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D6D3B.7040709@netconfcentral.com> Date: Mon, 07 Dec 2009 13:01:47 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis, issue 17, new reference figure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 21:04:19 -0000 Hi, There were minor changes to figure 1 approved at the meeting. The new figure shows notification data properly and also adds TLS mappings. The only issue that remained was changing the term 'Transport Protocol' to 'Secure Transports'. Does anybody have an argument for not emphasizing that NETCONF is only approved to run over secure transports? If not, the figure presented in slide 5 at the meeting will be used to update the current figure 1. Andy From andy@netconfcentral.com Tue Dec 8 08:39:35 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC41228C1F3 for ; Tue, 8 Dec 2009 08:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAUyIaOz5Ay1 for ; Tue, 8 Dec 2009 08:39:35 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id 2617928C200 for ; Tue, 8 Dec 2009 08:39:35 -0800 (PST) Received: (qmail 53052 invoked from network); 8 Dec 2009 16:39:24 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 08 Dec 2009 08:39:24 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: .mLYHEYVM1n8xvbkBTFQZjhmDc1PfetW8ZRWxkPbPu7eUMchvaFGvkqUeMplf45jMKcNUfFp_PLcipTgdxPSHD2NRF.7yuOgH9KIc..ge04cTuP0xFTWTrqYU91CQzayybiP8nWfvPMlbiOEE4xSIR9f6F4_2zb36NxGLqyVZwKVYMlRP3psUQhryweovGx1tys5hberTTstnknvOgYpCcu36ZTFq27PWpqmlA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1E80AC.1090306@netconfcentral.com> Date: Tue, 08 Dec 2009 08:37:00 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis, issue 18: lock and commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 16:39:36 -0000 Hi, There is an open issue regarding how the operation behaves if the candidate is locked by another session. There seems to be consensus that a lock on the running config by another session will cause the operation to fail. Since the contents of running will be the same as candidate (it it succeeds), it is not clear if this operation can ignore a lock on candidate or not. The WG needs to decide what to do here: A) Add text to sec. 8.3.4.1 saying the commit MUST fail if the candidate is locked by a different session B) Add text to sec. 8.3.4.1 saying it is implementation-specific whether the commit will be affected by a lock on candidate C) Add text to sec. 8.3.4.1 saying the commit MUST NOT fail because the candidate is locked by a different session D) Don't add any text; declare this to be a non-issue E) ??? [ed. opinion: this seems like an artificial corner-case due to poor lock usage, so if this is implementation-specific, it will not really harm interoperability. favor choice (B)] Andy From andy@netconfcentral.com Tue Dec 8 09:19:01 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0F93A6A33 for ; Tue, 8 Dec 2009 09:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgR1DyOL69h5 for ; Tue, 8 Dec 2009 09:19:00 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 0CA7B3A6A32 for ; Tue, 8 Dec 2009 09:18:57 -0800 (PST) Received: (qmail 23089 invoked from network); 8 Dec 2009 17:18:30 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 08 Dec 2009 09:18:29 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 6m_K4ScVM1lnnH8_cO9v9cMe2RjqfDILRnKbBVOvfEf2KD_d0vslLOhoE7KLZu31D2VutBeclC.1D4nxrTuK1UEdgcFmMrXMlRZU6slJpahekk4._8ZQNXgnrZCELL7hLTaEujjjVMnd7krgCIjKUP9W.kq88vQFRl.xT2Nmfd1ibijCVv9P_KwzR_zXronbgrRN0Eeg2Q_1hqm03UcxzLPh8gD9q3tS7qWESA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1E89D5.3090700@netconfcentral.com> Date: Tue, 08 Dec 2009 09:16:05 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis: issue 4: error-severity=warning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 17:19:01 -0000 Hi, There was no resolution to this issue, which is what should be done about warnings? The problem is that this behavior is associated with the base protocol capability, and changing it at all will affect existing clients. Since the WG does not want to change the protocol version, there can be no changes to the element. The WG needs to decide what to do about this issue: A) deprecate the 'warning' value -- add text that says it MUST NOT be used B) do nothing now; wait until the protocol version does increment and add support for warnings at that time C) add support for warnings now and increment the protocol version Andy From kwatsen@juniper.net Tue Dec 8 11:47:22 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A47A3A676A for ; Tue, 8 Dec 2009 11:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kr-p01q9L+PD for ; Tue, 8 Dec 2009 11:47:21 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 73E6D3A63D3 for ; Tue, 8 Dec 2009 11:47:21 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSx6tPaYJKPz37ezRLiyIhHAs1v1XfDJH@postini.com; Tue, 08 Dec 2009 11:47:11 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 8 Dec 2009 11:45:15 -0800 From: Kent Watsen To: 'Andy Bierman' , Phil Shafer Date: Tue, 8 Dec 2009 11:45:15 -0800 Thread-Topic: [Netconf] warnings Thread-Index: AcphWucQex7Oum10QVagwRHjziExnQW44s0Q Message-ID: <84600D05C20FF943918238042D7670FD3684C980B4@EMBX01-HQ.jnpr.net> References: <200911091538.nA9FcNHZ002893@idle.juniper.net> <4AF84547.70006@netconfcentral.com> In-Reply-To: <4AF84547.70006@netconfcentral.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 19:47:22 -0000 Andy Bierman writes: > I don't think the standard will ever use warnings. > Even the use-case above is not a real warning. It is just > part of the object behavior, as defined in the description-stmt. > A warning is needed when something not defined in the YANG module > happens during the server response. I want to use warnings in the rpc-reply for / to indic= ate when (and maybe where) implicit changes occurred. This is the suggesti= on I made when we were discussing system-creatable flag on the NETMOD list.= .. Kent From j.schoenwaelder@jacobs-university.de Tue Dec 8 11:56:43 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4E03A6A31 for ; Tue, 8 Dec 2009 11:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taast9Vvd14w for ; Tue, 8 Dec 2009 11:56:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5E09F3A692E for ; Tue, 8 Dec 2009 11:56:42 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86DB9C0084; Tue, 8 Dec 2009 20:56:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yh9SeVfLf8RV; Tue, 8 Dec 2009 20:56:30 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A132BC007F; Tue, 8 Dec 2009 20:56:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 46B9DF4DE69; Tue, 8 Dec 2009 20:56:29 +0100 (CET) Date: Tue, 8 Dec 2009 20:56:29 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091208195629.GD57532@elstar.local> Mail-Followup-To: Andy Bierman , NETCONF References: <4B1E89D5.3090700@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1E89D5.3090700@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF Subject: Re: [Netconf] 4741bis: issue 4: error-severity=warning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 19:56:43 -0000 On Tue, Dec 08, 2009 at 06:16:05PM +0100, Andy Bierman wrote: > Hi, > > There was no resolution to this issue, which is what > should be done about warnings? > > The problem is that this behavior is associated with the > base protocol capability, and changing it at all will > affect existing clients. Since the WG does not want to > change the protocol version, there can be no changes to > the element. > > The WG needs to decide what to do about this issue: > > A) deprecate the 'warning' value -- add text that says > it MUST NOT be used > > B) do nothing now; wait until the protocol version does > increment and add support for warnings at that time > > C) add support for warnings now and increment the protocol version I think A) with a note that a fix of this "feature" might be provided in NETCONF 1.1 is appropriate. (Perhaps we should even compile an appendix of known issues that are candidates to be addressed by a 1.1 version of the protocol.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Dec 8 12:12:10 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462ED3A692E for ; Tue, 8 Dec 2009 12:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv6hI+tebxIK for ; Tue, 8 Dec 2009 12:12:09 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A4AA73A6403 for ; Tue, 8 Dec 2009 12:12:08 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E17B9616002; Tue, 8 Dec 2009 21:11:57 +0100 (CET) Date: Tue, 08 Dec 2009 21:11:57 +0100 (CET) Message-Id: <20091208.211157.259449094.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1E89D5.3090700@netconfcentral.com> References: <4B1E89D5.3090700@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 4: error-severity=warning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 20:12:10 -0000 Andy Bierman wrote: > Hi, > > There was no resolution to this issue, which is what > should be done about warnings? > > The problem is that this behavior is associated with the > base protocol capability, and changing it at all will > affect existing clients. Since the WG does not want to > change the protocol version, there can be no changes to > the element. > > The WG needs to decide what to do about this issue: > > A) deprecate the 'warning' value -- add text that says > it MUST NOT be used I prefer A, but there is no reason to say that it MUST NOT be used, since there is no way to use it currently - that's why we deprecate it! /martin From mbj@tail-f.com Tue Dec 8 12:44:53 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927C03A677D for ; Tue, 8 Dec 2009 12:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IchF51HkaVIx for ; Tue, 8 Dec 2009 12:44:52 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AD4443A6403 for ; Tue, 8 Dec 2009 12:44:52 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C19BD616002; Tue, 8 Dec 2009 21:44:41 +0100 (CET) Date: Tue, 08 Dec 2009 21:44:41 +0100 (CET) Message-Id: <20091208.214441.139196284.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1E80AC.1090306@netconfcentral.com> References: <4B1E80AC.1090306@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 18: lock and commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 20:44:53 -0000 Andy Bierman wrote: > Hi, > > There is an open issue regarding how the > operation behaves if the candidate is locked by > another session. > > There seems to be consensus that a lock on the > running config by another session will cause > the operation to fail. > > Since the contents of running will be the same as > candidate (it it succeeds), it is not clear if > this operation can ignore a lock on candidate or not. > > The WG needs to decide what to do here: > > A) Add text to sec. 8.3.4.1 saying the commit MUST > fail if the candidate is locked by a different session I prefer A. This is what at least 3 implementations do (see the thread starting at http://www.ietf.org/mail-archive/web/netconf/current/msg04841.html) /martin > > B) Add text to sec. 8.3.4.1 saying it is implementation-specific > whether the commit will be affected by a lock on candidate > > C) Add text to sec. 8.3.4.1 saying the commit MUST NOT > fail because the candidate is locked by a different session > > D) Don't add any text; declare this to be a non-issue > > E) ??? > > > [ed. opinion: this seems like an artificial corner-case > due to poor lock usage, so if this is implementation-specific, > it will not really harm interoperability. favor choice (B)] > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@netconfcentral.com Tue Dec 8 12:56:40 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C0F3A692C for ; Tue, 8 Dec 2009 12:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbvDcRwvr7Tv for ; Tue, 8 Dec 2009 12:56:39 -0800 (PST) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id C19623A67A5 for ; Tue, 8 Dec 2009 12:56:39 -0800 (PST) Received: (qmail 44206 invoked from network); 8 Dec 2009 20:56:26 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 08 Dec 2009 12:56:26 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 6cfN1XYVM1m2rP0o8nH44sfzLgLPTCHMVxar6Wygky7ishcEN5bqvN9bIjfx7ZxfrsjWvoysB2OBKXnjtndBNGYOMYKIxMOsYZo2E_jseFNGhyvIwgKuubfQqd4vhdUpUZAhpZBsG3E0Ccz8GRlprT.GfgbbPgiNkpmcbsX2ryzYLpFn67eSAlymN1P9mmoE9_f9e3rxmGAz5_qBYBLLbWCcz9hA3JkEUVXyqgZ_OEaB.cge7mGgs3d.l6chqpLi X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1EBD63.6040507@netconfcentral.com> Date: Tue, 08 Dec 2009 12:56:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Kent Watsen References: <200911091538.nA9FcNHZ002893@idle.juniper.net> <4AF84547.70006@netconfcentral.com> <84600D05C20FF943918238042D7670FD3684C980B4@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3684C980B4@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 20:56:40 -0000 Kent Watsen wrote: > Andy Bierman writes: >> I don't think the standard will ever use warnings. >> Even the use-case above is not a real warning. It is just >> part of the object behavior, as defined in the description-stmt. >> A warning is needed when something not defined in the YANG module >> happens during the server response. > > I want to use warnings in the rpc-reply for / to indicate when (and maybe where) implicit changes occurred. This is the suggestion I made when we were discussing system-creatable flag on the NETMOD list... > I strongly object to any change in the server responses to the client without changing the NETCONF base protocol version. Any change at all in is a break in the contract implied by the RFC4741 base capability. > Kent > > Andy From andy@netconfcentral.com Tue Dec 8 13:49:39 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BED3A6856 for ; Tue, 8 Dec 2009 13:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29Mua7ZyKTdD for ; Tue, 8 Dec 2009 13:49:39 -0800 (PST) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 1131C3A67C0 for ; Tue, 8 Dec 2009 13:49:39 -0800 (PST) Received: (qmail 52268 invoked from network); 8 Dec 2009 21:49:26 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 08 Dec 2009 13:49:26 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Ea4KNakVM1loSd6TJ0i.DhAodbfghpbBJ0URJNGOAr1y2G08Xx6ZItrikgNysk4k.z7WOf_OzuJCWgshvMIt0HBs8nzMJhITUL9acEO4hxQkx6.H83LFrUnO0GB0baqrFTa74FwPMGXsqPjxETq1RP5Qlj0hSpeJjhVN4ru9JDcBNwEzsKzKyBQAYlnY4rVpJkA76e98.hSqSaxhYChQ0Z6hNthkxTkQuc2hhs1EyMWtlHYVxpLmBZfWaXTywZ1e X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1EC950.2010408@netconfcentral.com> Date: Tue, 08 Dec 2009 13:46:56 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 21:49:40 -0000 Hi, There is an open issue related to the server behavior for the current sessions if and when the set of available capabilities is changed. There seems to be some consensus for requiring the server to send an operation-failed error with an error-app-tag of 'capabilities-changed', in response to any received after the capability change. This would force a client to close the session and open a new one instead, in order to get the updated capabilities. Some people thought the server MAY send this error, instead of MUST/SHOULD send this error. There is no real way within the standard to specify how a server would know it is safe to continue. An important concern is how this new behavior is identified by the client. A 4741 server is not required to do anything special when a capability changes, so it must remain OK for a 4741 server to do whatever it is doing now, wrt/ this issue. There are no proposed edits at this time. The WG needs to decide on a basic solution approach first: A) server MUST send error; client needs to start a new session; increment protocol version so 4741 servers remain compliant. B) server MAY send error; client may need to start a new session C) server MUST send error; add additional mechanisms such as a clear-capability-changed-error() RPC and a capability-changed notification; increment protocol version D) do nothing; wait until NETCONF 1.1 to address this issue E) ??? Andy From j.schoenwaelder@jacobs-university.de Tue Dec 8 14:00:50 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8253A694A for ; Tue, 8 Dec 2009 14:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtOLrPJXobLm for ; Tue, 8 Dec 2009 14:00:48 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D6C113A6A7F for ; Tue, 8 Dec 2009 14:00:47 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C33BC007F for ; Tue, 8 Dec 2009 23:00:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2uR7sDZs4jUf; Tue, 8 Dec 2009 23:00:34 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96451C0044; Tue, 8 Dec 2009 23:00:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D46E0F4E146; Tue, 8 Dec 2009 23:00:32 +0100 (CET) Date: Tue, 8 Dec 2009 23:00:32 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20091208220032.GA57882@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.20 (2009-06-14) Subject: [Netconf] js last call comments on draft-ietf-netconf-monitoring-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 22:00:50 -0000 Hi, I have reviewed draft-ietf-netconf-monitoring-10, which had major text reorganizations from the previous version. Even though I found a few things worth to report (see below), I am very pleased by the effort the editors have put into this revision. I am going sequentially through the notes I have scribbled on my printout. Some if the issues are really minor editing nits while other are more substantial since I found text to be unclear or missing. 0) The document provides this definition of the term schema: Schema: A machine readable data model definition. I cross checked the YANG document and even though the YANG spec defines the terms such as 'schema node' or 'schema tree', it never defines the term schema. I would be nice if the YANG document would define the term 'schema' and then we would not need a definition of this term in the netconf monitoring document. 1) page 5, replace The NETCONF monitoring data defined in this document provides with The NETCONF monitoring data model defined in this document provides 2) page 5, remove duplicated dots YANG module provided in this document (see section 5).. 3) page 5, for consistency replace statistics (Container) with statistics (or add '(container)' for all the other branching nodes as well). I also think 'statistics' is misleading since there are statistics in other subtrees as well. Perhaps 'server' because we have accumulated per server statistics in this subtree? There is perhaps even a better name for this branch which I do not find at the moment - perhaps someone has a good suggestion. 4) page 7, improve consistency by replacing The data modeling language of the file/module. Current selection of xsd, yang, yin, rng and rnc. with The data modeling language the schema is written in (currently xsd, yang, yin, rng or rnc). and The XML namespace defined by the data model. with The XML namespace defined by the schema. (talk about schemas and not about a mixture of schemas, files, modules, data models). 5) page 7 I dislike the leaf name "identifier" - why can we not just call this the "name" of the schema? 6) page 7 I would have called leaf named "version" "revision" since that maps directly to the revision statement we have in YANG/YIN? But my feelings are less strong about this one compared to 5) above. 7) page 8, replace in [NETCONF Configuration Protocol]. with in [RFC4741]. 8) page 11, misleading text Since the same schema may be available in multiple locations and/or have multiple versions and/or multiple formats no particular attribute is unique. This statement is somewhat at odds with the fact that the key for the list listing schemas is (identifier, version, format) 9) page 11, suggested rewrite of The URL details returned in the list SHOULD facilitate retrieval from a network location via a means such as ftp or http. with The URLs returned in the list SHOULD facilitate retrieval from a network location via protocols such as ftp or http. I am also not sure what the SHOULD implies. Does it mean that if I use URLs, then I SHOULD choose the ftp or http scheme? Am I doing something wrong if I prefer to use https URLs? Am I supposed to provide URLs everytime or is a box implementing just the NETCONF access just fine? Some clarification would help me understand what the SHOULD requests me to implement. 10) page 11, MUST and SHOULD confusion Additionally the ability to retrieve a schema via NETCONF SHOULD be supported. When a schema is available on the device and the operation is supported by the NETCONF server a location value of 'NETCONF' MUST be used to indicate that it can be retrieved via NETCONF using the operation described in section 3.1. By reading the YANG module, I arrived at the conclusion that the operation is _not_ an optional feature. Hence, I do not see how the SHOULD and MUST go together here. It might be that this is a wording issue and the editors had different intentions in mind from what the text actually says. (would be nice to have a NETCONF URI format so the special case would not be needed by I understand that this is out of scope) 11) page 11, terminology and unclarity The NETCONF server returns a list of data models available for retrieval. For consistency, I think the text should say that the server returns a list of schemas (not data models). The unclarity comes from the question whether a server can provide arbitrary schemas (e.g. the superset of all schemas of a certain vendor) or whether there is an implicit assumption that only schemas are listed that are implemented on the device. I think this needs to be clarified by adding description statements to the 'schemas' and 'schema' schema nodes. 12) page 12, consistency with YANG The filenames shown in the examples for YANG modules should follow the YANG guidelines (note that the choice of the separator is still an open issue discussed on the NETMOD mailing list but the '-' is clearly not what YANG suggests or what is being discussed). 13) page 16, replace "RFC XXXX: NETCONF Monitoring Schema"; with "RFC XXXX: YANG Module for NETCONF Monitoring"; 14) page 19, rewrite "The /netconf-state subtree is the root of the monitoring data model. It acts as the container for the other monitored data."; with "The netconf-state container is the root of the monitoring data model."; 15) page 19, rewrite (and request for clarification) container capabilities { description "The list of currently provided NETCONF capabilities exchanged during session setup (i.e. hello)."; with container capabilities { description "The capabilities container provides the list of currently supported NETCONF capabilities as they would be announced during session setup."; Note that I am guessing here since the original text is not clear to me. What does "currently provided NETCONF capabilities exchanged during session setup" mean in case a server dynamically picks up new capabilities, in which case "currently provided" might be different from "during session setup". 16) page 19, rewrite description "List of NETCONF configuration datastores (e.g. running, startup, candidate) supported on this device and related information."; with description "The datastores container provides the list of NETCONF configuration datastores (e.g. running, startup, candidate) supported on this device and related information."; 17) page 20,21 I suggest to add 'reference' statements for 'lock-id', 'lock-info' and 'locked-nodes' to reference the partial locking document. 18) page 21, inconsistency with partial locking The scope of the partial lock is defined by the list of locked nodes. This list can change over time."; My reading of the partial locking document has been that the set expression is only evaluate once and that the set of locked nodes does not change over time. 19) page 22, rewrite "Includes session specific data for NETCONF management sessions. with "The sessions container includes session specific data for NETCONF management sessions. (write full sentences) 20) page 22,23, inconsistent text "Includes session specific data for NETCONF management sessions. "Unique identifier for the session. If the session is a NETCONF session, this value is the NETCONF session identifier. If the first statement is true, then the second is not needed since we only deal with NETCONF sessions. Likewise, if the second statement is needed, then the first one should be rewritten. More confusion then comes from this additional text: For purposes of NETCONF management all sessions are one of: Known session: any session which can be managed by the NETCONF server SHOULD be reported in this table. Unknown session: such sessions are not managed by the NETCONF server and map to NETCONF session identifier 0. These MUST be excluded from the list as a result."; Now we seem to have NETCONF sessions, non-NETCONF sessions, known sessions and unknown session. Furthermore, the MUST does not make sense since the session-id does not allow this value to be represented. I think this text needs to be simplified. 21) Make sure all statements that should have a description statement according to the usage guidelines have a description statement. 22) It is not always clear why some leafs are marked mandatory true or not. For example, why is 'locked-by-session' not mandatory? Is this to allow implementations to simply not report the id of the locking session or is this to deal with locks that are not associated with a NETCONF session-id? 23) page 23, my usual rambling on username... leaf username { type string; description "If present, the username contains an identifier which can be used to uniquely identify an individual client (human or machine). This is likely to be implementation specific and subject to the security requirements of the device vendor and/or operators, e.g., an SSH user, a host RSA fingerprint or other identifier deemed acceptable."; } If we ever do access control, we likely need a concept such as a username on whoes behalf on operation / access is performed. Once we get there, we will have to make the username predictable for the security administrator and the "e.g." list above will not work anymore. Perhaps it is better to remove the second sentence in the description above and instead stay very clearly. "The algorithm how a NETCONF server derives a username from the authenticated identity of a NETCONF session (e.g. an SSH user name or an X.509 certificate) is currently not standardized and may be the subject of future standardization work." This text makes it clear that this mapping is currently implementation specific and might change once we have to standardize this. 24) page 23, my usual rambling on source-host leaf source-host { type inet:host; description "Host identifier (IP address or name) of the client."; } One could or perhaps should add a warning that (a) the IP address may be confusing if the client is behind a NAT and (b) that multiple sessions originating from the same network interface will not be distinguishable. Furthermore, I like to see some guidance when an implementation should report the name instead of the IP address. Is the idea that a server does a DNS reverse lockup (which does not need to be consistent with forward lookups)? If yes, is this lookup to be done when the session gets established or when I retrieve the object? 25) page 27, security considerations I do not know what the guidelines for YANG modules will be but if we following SMIv2 MIB guidelines, then more text is needed. The YANG usage document currently says: In particular, writable module objects that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out; similarly, readable module objects that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. 26) page 15, 29, namespace prefix The document suggests the prefix 'ns' (probably from netconf state). Since we expect to us 'nc' for the netconf definition itself, we could use something like 'ncm' for netconf monitoring instead of 'ns' (but note that I do not have a strong opinion about this). 27) I think the [YANG] and [Common YANG Data Types] references must be normative. /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@netconfcentral.com Tue Dec 8 14:10:53 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C333A6831 for ; Tue, 8 Dec 2009 14:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZNay0fegVQN for ; Tue, 8 Dec 2009 14:10:52 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 14EA83A67C0 for ; Tue, 8 Dec 2009 14:10:52 -0800 (PST) Received: (qmail 21098 invoked from network); 8 Dec 2009 22:10:39 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 08 Dec 2009 14:10:39 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: KT9ME4MVM1lleFidb6XXwDj4v4QOLrzBLWElvz2UdOW1d6tNYRTtckWtwkIwL4CVYAqWeKjxWp8jR313cCb9o1zecDOYH61vY887ffHZ0DIqmVRpKfY8BlwptUt3JN2VlfzH5VnGkusiXe7C7xwaKUpxcDJS4oPjJUeSAwa0SDCFgcbCNRc9WWtgY6JgiTvHxRdVPnuYQ1t2eGd0k.WZMbQFDCJAsY4ui0OrwKZCPlrD4XhiVa2d5y9ABvMwU70W X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1ECEC7.5080604@netconfcentral.com> Date: Tue, 08 Dec 2009 14:10:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 22:10:53 -0000 Hi, First there was the Robust Configuration draft, which proposed a verified-commit procedure. Then there was some consensus towards decoupling the verify and commit procedures. Then there was a suggestion to improve the commit procedure with a new capability. Old clients would still work because there would be 1 or more new parameters that must be present to select the new behavior. The new confirmed-commit-1.1 capability would add a parameter to the operation. There are no proposed edits at this time. The WG needs to decide on a basic solution approach first: A) add a new capability which changes the commit procedure to allow the original server to terminate without canceling the confirmed commit; detailed proposal from Martin is still needed, and WG consensus on all the details is needed B) start a new draft for this work (now or later), instead of starting this new work now as part of the 4741bis 'cleanup' charter C) do nothing; do not change the commit procedure Andy From j.schoenwaelder@jacobs-university.de Tue Dec 8 14:12:17 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F763A6908 for ; Tue, 8 Dec 2009 14:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Addpc0gnwM2f for ; Tue, 8 Dec 2009 14:12:14 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 134C63A67B0 for ; Tue, 8 Dec 2009 14:12:13 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C6FDC0083; Tue, 8 Dec 2009 23:12:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id T8Qdqfo9We8L; Tue, 8 Dec 2009 23:12:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A66BC0044; Tue, 8 Dec 2009 23:12:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0D48BF4E2C2; Tue, 8 Dec 2009 23:12:00 +0100 (CET) Date: Tue, 8 Dec 2009 23:11:59 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091208221159.GB57882@elstar.local> Mail-Followup-To: Andy Bierman , NETCONF References: <4B1EC950.2010408@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1EC950.2010408@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 22:12:17 -0000 On Tue, Dec 08, 2009 at 10:46:56PM +0100, Andy Bierman wrote: > There are no proposed edits at this time. > The WG needs to decide on a basic solution > approach first: > > A) server MUST send error; client needs to > start a new session; increment protocol version > so 4741 servers remain compliant. > > B) server MAY send error; client may need to > start a new session B) is not very helpful for clients since they can't rely on MAY behaviour. If the number of real deployments where capabilities changes is large enough that we can't do A), we should not do B) instead. > C) server MUST send error; add additional mechanisms > such as a clear-capability-changed-error() RPC > and a capability-changed notification; > increment protocol version And / or add a hello() operation that can be invoked to synchronize a client to the capabilities of a server by essentially doing another hello exchange with proper RPC framing. > D) do nothing; wait until NETCONF 1.1 to address this issue As long as our goal for the RFC4741 update is to not to bump the protocol version number, I suggest we do D) by adding explicit text that the behaviour in this case is undefined and adding an item to a "things to consider for 1.1" appendix so we can track this issue and people are warned that something might change here in NETCONF 1.1. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Tue Dec 8 14:21:04 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51BA3A6942 for ; Tue, 8 Dec 2009 14:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-szGLjS69MG for ; Tue, 8 Dec 2009 14:21:04 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 2C6E63A67C0 for ; Tue, 8 Dec 2009 14:21:04 -0800 (PST) Received: (qmail 8701 invoked from network); 8 Dec 2009 22:20:51 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 08 Dec 2009 14:20:50 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: HCmaONYVM1lurf0x8dJLL6p73hMHzQnmzCc4I45tJnmgvXxHbN4AX8xhsKSpA2HiminE.XsOSTGTdLNSL917wt7dUnB..s7QBeCqhI8kIi2dEM5lb8nTJk516.R6X4jpXsbLXQzLWRKmAPDbeZmNbEzw2R__2VYedFk9nFIOsZAhj5cYYQz4riKh3tWOWNIqmQRDI8iCnBRoFWSGVPf7_O4M3H18CtIk4Ml0LZeX395BK44HCQg4Ee_0kOQG5bGD X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1ED12A.2040907@netconfcentral.com> Date: Tue, 08 Dec 2009 14:20:26 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , NETCONF References: <4B1EC950.2010408@netconfcentral.com> <20091208221159.GB57882@elstar.local> In-Reply-To: <20091208221159.GB57882@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 22:21:05 -0000 Juergen Schoenwaelder wrote: > On Tue, Dec 08, 2009 at 10:46:56PM +0100, Andy Bierman wrote: > >> There are no proposed edits at this time. >> The WG needs to decide on a basic solution >> approach first: >> >> A) server MUST send error; client needs to >> start a new session; increment protocol version >> so 4741 servers remain compliant. >> >> B) server MAY send error; client may need to >> start a new session > > B) is not very helpful for clients since they can't rely on MAY > behaviour. If the number of real deployments where capabilities > changes is large enough that we can't do A), we should not do B) > instead. > >> C) server MUST send error; add additional mechanisms >> such as a clear-capability-changed-error() RPC >> and a capability-changed notification; >> increment protocol version > > And / or add a hello() operation that can be invoked to synchronize a > client to the capabilities of a server by essentially doing another > hello exchange with proper RPC framing. > >> D) do nothing; wait until NETCONF 1.1 to address this issue > > As long as our goal for the RFC4741 update is to not to bump the > protocol version number, I suggest we do D) by adding explicit text > that the behaviour in this case is undefined and adding an item to a > "things to consider for 1.1" appendix so we can track this issue and > people are warned that something might change here in NETCONF 1.1. > (D) seems OK to me. I prefer to get 4741bis done ASAP, without any new capabilities. Then later, bundle a lot of new features/improvements into a 1.1 version released in late 2011. When YANG is published and used a bit, it will be more clear how NETCONF needs to evolve to support it. > /js > Andy From phil@juniper.net Wed Dec 9 05:49:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E65C28C18E for ; Wed, 9 Dec 2009 05:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI07w6mKs33L for ; Wed, 9 Dec 2009 05:49:15 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 7811D28C12D for ; Wed, 9 Dec 2009 05:49:14 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSx+qzVOsvOZZg1p8QuJma0EYllDISjbm@postini.com; Wed, 09 Dec 2009 05:49:04 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Wed, 9 Dec 2009 05:45:29 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 05:45:29 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 05:45:28 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 05:45:28 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB9DjQj62251; Wed, 9 Dec 2009 05:45:27 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nB9DVfUH094943; Wed, 9 Dec 2009 13:31:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912091331.nB9DVfUH094943@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091208221159.GB57882@elstar.local> Date: Wed, 9 Dec 2009 08:31:41 -0500 From: Phil Shafer X-OriginalArrivalTime: 09 Dec 2009 13:45:28.0372 (UTC) FILETIME=[DE238F40:01CA78D5] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 13:49:16 -0000 Juergen Schoenwaelder writes: >B) is not very helpful for clients since they can't rely on MAY >behaviour. If the number of real deployments where capabilities >changes is large enough that we can't do A), we should not do B) >instead. But it is helpful, since the server can look at the RPC before sending an error. Clients would not be forced to redo a connection just to issue a "reboot" operation after a software install. I also lean towards (D) since I can't see adding this error in a backwards-compatible way. Thanks, Phil From mbj@tail-f.com Wed Dec 9 13:15:08 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A607A3A692F for ; Wed, 9 Dec 2009 13:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eytDvPEJ7zMz for ; Wed, 9 Dec 2009 13:15:06 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 05F063A6951 for ; Wed, 9 Dec 2009 13:15:06 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7976876C68E; Wed, 9 Dec 2009 22:14:53 +0100 (CET) Date: Wed, 09 Dec 2009 22:14:52 +0100 (CET) Message-Id: <20091209.221452.236221846.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1EC950.2010408@netconfcentral.com> References: <4B1EC950.2010408@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 21:15:08 -0000 Andy Bierman wrote: > There seems to be some consensus for requiring the server > to send an operation-failed error with an error-app-tag > of 'capabilities-changed', in response to any > received after the capability change. > > This would force a client to close the session and open a > new one instead, in order to get the updated capabilities. > > Some people thought the server MAY send this error, > instead of MUST/SHOULD send this error. > There is no real way within the standard to > specify how a server would know it is safe > to continue. > > An important concern is how this new behavior is > identified by the client. A 4741 server is > not required to do anything special when a capability > changes, so it must remain OK for a 4741 server to > do whatever it is doing now, wrt/ this issue. The problem is that 4741 doesn't say if the capabilities can change during a session or not. This is what we need to clarify. If we do alternative D - do nothing - this will remain unclear, and interoperability will suffer. If a server is allowed to change capabilities without letting the client know, what good is the hello message anyway? In the extreme case, I can let my server advertise all known capabilites, and then claim that 1 millisecond later my capabilites changed into "base:1.0" only. I think it is clear from 4741 that the advertisement of capabilites is to let the client know what to expect from the server - it is the definition of the contract between the client and server. Without a resync mechanism, I think the only way to handle this is to not allow capabilites to change. This is why I proposed the following text in http://www.ietf.org/mail-archive/web/netconf/current/msg04512.html: The capabilities of a NETCONF server may change over time. However, once a NETCONF server has announced its capabilities in the message, the capabilities for that session MUST NOT change. A server MUST reply with a 'capabilities-changed' error if the client sends a request which is affected by a modified capability. And maybe add: A server MAY choose to send 'capabilities-changed' as the response to any request other than if its capabilities has changed. Provided that 'capabilities-changed' is an error-app-tag, this is backwards compatible. If we want to create a new fancy mechanism to resync modified capabilities, I agree we can do that in netconf 1.1. /martin > There are no proposed edits at this time. > The WG needs to decide on a basic solution > approach first: > > A) server MUST send error; client needs to > start a new session; increment protocol version > so 4741 servers remain compliant. > > B) server MAY send error; client may need to > start a new session > > C) server MUST send error; add additional mechanisms > such as a clear-capability-changed-error() RPC > and a capability-changed notification; > increment protocol version > > D) do nothing; wait until NETCONF 1.1 to address this issue > > E) ??? > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@netconfcentral.com Wed Dec 9 13:29:02 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D3C3A6403 for ; Wed, 9 Dec 2009 13:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMoV29NFOZUy for ; Wed, 9 Dec 2009 13:29:01 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 7E79B3A6AF7 for ; Wed, 9 Dec 2009 13:29:01 -0800 (PST) Received: (qmail 47795 invoked from network); 9 Dec 2009 21:28:48 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 09 Dec 2009 13:28:47 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 95jOFywVM1n2VB08U0YO63HufapIsfDz5dpyOWXVKZdAWajvq5ZU1dwu0rDRUT.0MyiysIPvNlup5qf3Lr0SPIigkcdRsrXG.tBz6mEQbmTKJIhjbMTkirxT5U4qCo6knWoAiIjwdRJR_q27pi3NXtJLr1Pyg9KrwqnARTTSJj70XCipMe9fTWYocMYv62b66X83zHMltpkFHOl75ID69ZPEsZi_772xo5P3d_Y0y0rR.0fq_11UNsIt9HFyR.OtXYcoBdQINQYZ.N.j2uD.BDzVpT_uqP6A X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B201670.7020506@netconfcentral.com> Date: Wed, 09 Dec 2009 13:28:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1EC950.2010408@netconfcentral.com> <20091209.221452.236221846.mbj@tail-f.com> In-Reply-To: <20091209.221452.236221846.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 21:29:02 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> There seems to be some consensus for requiring the server >> to send an operation-failed error with an error-app-tag >> of 'capabilities-changed', in response to any >> received after the capability change. >> >> This would force a client to close the session and open a >> new one instead, in order to get the updated capabilities. >> >> Some people thought the server MAY send this error, >> instead of MUST/SHOULD send this error. >> There is no real way within the standard to >> specify how a server would know it is safe >> to continue. >> >> An important concern is how this new behavior is >> identified by the client. A 4741 server is >> not required to do anything special when a capability >> changes, so it must remain OK for a 4741 server to >> do whatever it is doing now, wrt/ this issue. > > The problem is that 4741 doesn't say if the capabilities can change > during a session or not. This is what we need to clarify. > > If we do alternative D - do nothing - this will remain unclear, and > interoperability will suffer. > > If a server is allowed to change capabilities without letting the > client know, what good is the hello message anyway? In the extreme > case, I can let my server advertise all known capabilites, and then > claim that 1 millisecond later my capabilites changed into "base:1.0" > only. > > I think it is clear from 4741 that the advertisement of capabilites is > to let the client know what to expect from the server - it is the > definition of the contract between the client and server. Without a > resync mechanism, I think the only way to handle this is to not allow > capabilites to change. > > This is why I proposed the following text in > http://www.ietf.org/mail-archive/web/netconf/current/msg04512.html: > > The capabilities of a NETCONF server may change over time. However, > once a NETCONF server has announced its capabilities in the > message, the capabilities for that session MUST NOT change. A > server MUST reply with a 'capabilities-changed' error if the client > sends a request which is affected by a modified capability. > > And maybe add: > > A server MAY choose to send 'capabilities-changed' as the response > to any request other than if its capabilities has > changed. > > I agree with Phil that this is a vendor-specific detail, and there are many mechanisms that might be used to deal with changing capabilities, or the specific operation may not be affected by the capability change at all. > Provided that 'capabilities-changed' is an error-app-tag, this is > backwards compatible. > > If we want to create a new fancy mechanism to resync modified > capabilities, I agree we can do that in netconf 1.1. > > Why bother doing anything now? We are lumping all capabilities together, including unknown vendor capabilities, and declaring a very harsh CLR for no apparent reason. If you want to say that those rules apply only to standard capabilities, and not vendor or YANG module capabilities, then that is OK. I have mechanisms implemented that automatically keep the modules in synch on the client, so why should I lock down all sessions just because a module was loaded into the system? That is an operationally-unfriendly side effect of the operation. > /martin > Andy > >> There are no proposed edits at this time. >> The WG needs to decide on a basic solution >> approach first: >> >> A) server MUST send error; client needs to >> start a new session; increment protocol version >> so 4741 servers remain compliant. >> >> B) server MAY send error; client may need to >> start a new session >> >> C) server MUST send error; add additional mechanisms >> such as a clear-capability-changed-error() RPC >> and a capability-changed notification; >> increment protocol version >> >> D) do nothing; wait until NETCONF 1.1 to address this issue >> >> E) ??? >> >> >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > From mbj@tail-f.com Wed Dec 9 14:02:20 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976933A6997 for ; Wed, 9 Dec 2009 14:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxmDrbMIWgjr for ; Wed, 9 Dec 2009 14:02:19 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 03BDE3A67AE for ; Wed, 9 Dec 2009 14:02:18 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9C9BE76C68B; Wed, 9 Dec 2009 23:02:06 +0100 (CET) Date: Wed, 09 Dec 2009 23:02:05 +0100 (CET) Message-Id: <20091209.230205.258310928.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B201670.7020506@netconfcentral.com> References: <4B1EC950.2010408@netconfcentral.com> <20091209.221452.236221846.mbj@tail-f.com> <4B201670.7020506@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 22:02:20 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > This is why I proposed the following text in > > http://www.ietf.org/mail-archive/web/netconf/current/msg04512.html: > > > > The capabilities of a NETCONF server may change over time. However, > > once a NETCONF server has announced its capabilities in the > > message, the capabilities for that session MUST NOT change. A > > server MUST reply with a 'capabilities-changed' error if the client > > sends a request which is affected by a modified capability. > > > > And maybe add: > > > > A server MAY choose to send 'capabilities-changed' as the response > > to any request other than if its capabilities has > > changed. > > > > > > > I agree with Phil that this is a vendor-specific > detail, and there are many mechanisms that might be used > to deal with changing capabilities, or the specific operation > may not be affected by the capability change at all. The last issue is covered by the text I proposed. > > Provided that 'capabilities-changed' is an error-app-tag, this is > > backwards compatible. > > > > If we want to create a new fancy mechanism to resync modified > > capabilities, I agree we can do that in netconf 1.1. > > > > > > Why bother doing anything now? > We are lumping all capabilities together, > including unknown vendor capabilities, > and declaring a very harsh CLR for no apparent reason. > > If you want to say that those rules apply only > to standard capabilities, and not vendor or YANG module > capabilities, then that is OK. > > I have mechanisms implemented that automatically keep the > modules in synch on the client, so why should I lock down all sessions > just because a module was loaded into the system? That is > an operationally-unfriendly side effect of the operation. First of all, if you read my proposal you will see that I did not suggest that you lock down all sessions just because a module is loaded into the system. Second - the reason for doing anything at all is interoperability. Maybe my client does not understand your vendor specific mechanisms for keeping capabilities in synch. By using a standardized error, it can still handle the situation. If the WG does not want to solve the problem, I still think D is a bad choice. We should at least say that it is implementation specific if capabilites can change during the session or not. /martin From luchuk@snmp.com Mon Dec 14 08:24:39 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B273A6A11 for ; Mon, 14 Dec 2009 08:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOoU0YAEBQMg for ; Mon, 14 Dec 2009 08:24:35 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 8D0123A6806 for ; Mon, 14 Dec 2009 08:24:34 -0800 (PST) Received: from sol8.snmp.com (sol8.snmp.com [192.147.142.173]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA22984; Mon, 14 Dec 2009 11:24:20 -0500 (EST) Received: from sol8 (localhost [127.0.0.1]) by sol8.snmp.com (8.11.7p1+Sun/8.11.2/snmpclient.mc-011018) with ESMTP id nBEGOKx27967; Mon, 14 Dec 2009 11:24:20 -0500 (EST) Message-Id: <200912141624.nBEGOKx27967@sol8.snmp.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Dec 2009 11:24:20 -0500 From: Alan Luchuk Subject: [Netconf] Clarification of "operation" attribute X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:24:39 -0000 Hello, I have questions about the specific behavior of the NETCONF protocol operation with the different values of the "operation" attribute. RFC 4741 bis does not seem to expand and/or clarify the corresponding sec- tion(s) of RFC 4741. In RFC 4741, the "operation" attribute behavior is described on pages 34 and 35. The meaning of "merge" is not clear. As an example, for a con- ceptual table, does merge mean: - Add a row in the configuration data to the table ONLY IF the row in the configuration data DOES NOT ALREADY EXIST in the table. Return an if the row in the configuration data ALREADY EXISTS in the table. Or does "merge" mean: - Add a row in the configuration data to the table. If the row in the configuration data DOES NOT ALREADY EXIST in the table, then add the row. If the row in the configuration data ALREADY EXISTS in the table, then REPLACE the values in the table with the values in the configuration data. Also, from the description of the "data-exists" and "data-missing" error messages, documented on page 72 of RFC 4741, it appears that the "replace" and "delete" operations FAIL if the the configuration data specifies nonexistent rows in a conceptual table. It would clarify RFC 4741 (bis) if the text on page 34 would include, or at least reference, the text from page 72. The text explanation of the "create" operation (RFC 4741, page 35) clearly explains that the create operation returns an if the configur- ation data already exists. It would be clarify RFC 4741 bis if analogous text would be added to the sections describing the "replace" and "delete" operations. Would someone please point me to the proper sections of RFC 4741 (or bis) where the correct behavior is clearly explained? Thanks in advance! Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From andy@netconfcentral.com Mon Dec 14 09:21:17 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74663A68F9 for ; Mon, 14 Dec 2009 09:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5Cw9A4xPrHE for ; Mon, 14 Dec 2009 09:21:13 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 01BCB3A6A13 for ; Mon, 14 Dec 2009 09:20:55 -0800 (PST) Received: (qmail 94670 invoked from network); 14 Dec 2009 17:20:43 -0000 Received: from adsl-67-121-105-196.dsl.irvnca.pacbell.net (andy@67.121.105.196 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 14 Dec 2009 09:20:43 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: E1KVfSMVM1nP6eezqYieGssZdTzg_8EZr0DSGGZKEXglWPiPfrJlfQBp_rXXGAkwC3wY7VKuBi4_XuF6wcx0d2Tve_zeBEvLm4v97IOYS5gI.jb4RwX8isrFQnpQnU9uWg2ZwqVXLRPZIm9rogR8TcGW_9F86j9RcpK6ZP8M3cRgfln8ePOtm422ZIvrggbQOXmoyUajpsq7vaqScVQDD9Vp7PP3i2RgpUi75GRgTUxTq2y_oesjBWupKh4nO4eA X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B267411.5080903@netconfcentral.com> Date: Mon, 14 Dec 2009 09:21:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alan Luchuk References: <200912141624.nBEGOKx27967@sol8.snmp.com> In-Reply-To: <200912141624.nBEGOKx27967@sol8.snmp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Clarification of "operation" attribute X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 17:21:17 -0000 Alan Luchuk wrote: > Hello, > > I have questions about the specific behavior of the NETCONF > protocol operation with the different values of the "operation" attribute. > RFC 4741 bis does not seem to expand and/or clarify the corresponding sec- > tion(s) of RFC 4741. > > In RFC 4741, the "operation" attribute behavior is described on pages 34 > and 35. The meaning of "merge" is not clear. As an example, for a con- > ceptual table, does merge mean: > > - Add a row in the configuration data to the table ONLY IF the row in the > configuration data DOES NOT ALREADY EXIST in the table. Return an > if the row in the configuration data ALREADY EXISTS in the > table. > > Or does "merge" mean: > > - Add a row in the configuration data to the table. If the row in the > configuration data DOES NOT ALREADY EXIST in the table, then add > the row. If the row in the configuration data ALREADY EXISTS in the > table, then REPLACE the values in the table with the values in the > configuration data. > Yes, where REPLACE applies only to the values explicitly contained in the PDU. Any nodes already in the config (or whatever subtree) remain in the config. > Also, from the description of the "data-exists" and "data-missing" error > messages, documented on page 72 of RFC 4741, it appears that the "replace" > and "delete" operations FAIL if the the configuration data > specifies nonexistent rows in a conceptual table. It would clarify RFC > 4741 (bis) if the text on page 34 would include, or at least reference, > the text from page 72. I will look into changing the text in 4741bis. The replace operation does not fail if the data is not in the target config (unlike delete). PDU: fred barney target config: wilma betty Result of default-operation='merge' (order may be different on every server for top-level elements) fred barney betty Result of default-operation=replace: fred barney Result of default-operation=none: wilma betty > > The text explanation of the "create" operation (RFC 4741, page 35) clearly > explains that the create operation returns an if the configur- > ation data already exists. It would be clarify RFC 4741 bis if analogous > text would be added to the sections describing the "replace" and "delete" > operations. > OK > Would someone please point me to the proper sections of RFC 4741 (or bis) > where the correct behavior is clearly explained? > I'll look at the text and send any suggested changes to the mailing list. > Thanks in advance! > > Regards, > --Alan > Andy From mbj@tail-f.com Mon Dec 14 12:00:18 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714CC28C160 for ; Mon, 14 Dec 2009 12:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFEfw5Q8E1CF for ; Mon, 14 Dec 2009 12:00:17 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D44A528C1CC for ; Mon, 14 Dec 2009 12:00:10 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 774EE616006; Mon, 14 Dec 2009 20:59:57 +0100 (CET) Date: Mon, 14 Dec 2009 20:59:56 +0100 (CET) Message-Id: <20091214.205956.167743377.mbj@tail-f.com> To: luchuk@snmp.com From: Martin Bjorklund In-Reply-To: <200912141624.nBEGOKx27967@sol8.snmp.com> References: <200912141624.nBEGOKx27967@sol8.snmp.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Clarification of "operation" attribute X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 20:00:18 -0000 Hi, Alan Luchuk wrote: > Hello, > > I have questions about the specific behavior of the NETCONF > protocol operation with the different values of the "operation" attribute. > RFC 4741 bis does not seem to expand and/or clarify the corresponding sec- > tion(s) of RFC 4741. > > In RFC 4741, the "operation" attribute behavior is described on pages 34 > and 35. The meaning of "merge" is not clear. Yes, and I agree with Andy that we should try to clarify this. However, note that to some extent this is data model specific. The YANG draft specifies what merge means for different types of nodes. > Also, from the description of the "data-exists" and "data-missing" error > messages, documented on page 72 of RFC 4741, it appears that the "replace" > and "delete" operations FAIL if the the configuration data > specifies nonexistent rows in a conceptual table. I have already fixed this in the sources for 4741bis. /martin From andyb@iwl.com Tue Dec 15 12:31:44 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB06F3A6914 for ; Tue, 15 Dec 2009 12:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn+McUuw1HlD for ; Tue, 15 Dec 2009 12:31:44 -0800 (PST) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id 48F9A3A68CF for ; Tue, 15 Dec 2009 12:31:44 -0800 (PST) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 145D713D3371; Tue, 15 Dec 2009 15:31:29 -0500 (EST) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id DCC7913D3269; Tue, 15 Dec 2009 15:31:28 -0500 (EST) Message-ID: <4B27F252.9020203@iwl.com> Date: Tue, 15 Dec 2009 12:32:18 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] email address change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:01:33 -0000 Hi, I am retiring andy@netconfcentral.com and using andyb@iwl.com from now on, because I have joined InterWorking Labs to fully develop my NETCONF/YANG implementation. The http://www.netconfcentral.org/ WEB site will continue to exist and provide free information and online tools for NETCONF and YANG. thanks, Andy From andyb@iwl.com Tue Dec 15 12:47:05 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE203A68D9 for ; Tue, 15 Dec 2009 12:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iyE1LFcGhv6 for ; Tue, 15 Dec 2009 12:47:04 -0800 (PST) Received: from smtp194.iad.emailsrvr.com (smtp194.iad.emailsrvr.com [207.97.245.194]) by core3.amsl.com (Postfix) with ESMTP id AFDA63A68CF for ; Tue, 15 Dec 2009 12:47:04 -0800 (PST) Received: from relay9.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id F2F4D1E336B; Tue, 15 Dec 2009 15:46:50 -0500 (EST) Received: by relay9.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AF56B1E6150; Tue, 15 Dec 2009 15:46:50 -0500 (EST) Message-ID: <4B27F5EC.3010501@iwl.com> Date: Tue, 15 Dec 2009 12:47:40 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] Yuma Tools announcement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:01:41 -0000 Hi, A new NETCONF/YANG toolkit is available called Yuma Tools. The binary license is free, and the most popular linux distributions (and MacOSX 10.5) will be supported. The toolkit includes: * yangcli: NETCONF-over-SSH client application * netconfd: NETCONF-over-SSH server for linux or MacOSX * netconf-subsystem: OpenSSH to netconfd thin client * yangdump: YANG compiler * yangdiff: YANG semantic comparison application * libtoaster: example modular server instrumentation library * PDF user manuals All current versions of all NETCONF/YANG drafts are supported, except the :url and :partial-lock capabilities, which will be implemented soon. Some proprietary content is also implemented, including a complete access control system called NACM. http://www.netconfcentral.org/modules/yuma-nacm/2009-10-21 More information is available at http://yuma.iwl.com/ thanks, Andy From bertietf@bwijnen.net Wed Dec 16 01:10:12 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235E43A67D8 for ; Wed, 16 Dec 2009 01:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_05=-1.11, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXQ8nPUqK9Pz for ; Wed, 16 Dec 2009 01:10:10 -0800 (PST) Received: from relay.versatel.net (relay56.tele2.vuurwerk.nl [62.250.3.56]) by core3.amsl.com (Postfix) with ESMTP id A07383A67B2 for ; Wed, 16 Dec 2009 01:10:09 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1NKptL-0008GA-3P for netconf@ietf.org; Wed, 16 Dec 2009 10:09:55 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" References: <8051C60F8BA0481692D907F1ED03D1C4@BertLaptop> In-Reply-To: <8051C60F8BA0481692D907F1ED03D1C4@BertLaptop> Date: Wed, 16 Dec 2009 10:09:43 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_10BE_01CA7E37.E327FC30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Subject: [Netconf] We have WG consensus on doing a rfc4742bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 09:10:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_10BE_01CA7E37.E327FC30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG participants, no-one objected to the below. So hereby we have confirmed that the WG has consensus to work on a rfc4742bis document. So we (WG chairs) will ask for the milestone updates to the WG charter = page. And Margaret is ready and eager to post the first draft as a WG = document. There was already some discussion on the mailing list, and hopefully the initial I-D will cause some more. Bert and Mehmet ----- Original Message -----=20 From: Bert Wijnen (IETF)=20 To: Netconf=20 Sent: Tuesday, November 24, 2009 10:29 PM Subject: [Netconf] Poll for WG consensus on doing a rfc4742bis WG participants, The two authors/editors of RFC4742 have agreed to pick up the pen if = we indeed want to produce a RFC4742bis. Maragert will do the bulk of the editing though. At the IETF76 meeting we had consensus to do an RFC4742bis.=20 Our current WG charter allows for this. All we need to do is add a = milestone. The proposed milestones are: - dec 2009 publish initial wg draft for rfc4742bis - 1Q 2010 WG Last Call rfc4742bis - 2Q 2010 send rfc4742bis to IESG for publication as stdsa track = RFC. But we need to confirm this on the mailing list. So please speak up ASAP, but no later than Dec 1st, if you feel we = should not undertake that work. We (WG-chairs) will take silence as agreement = this time. Bert & Mehmet -------------------------------------------------------------------------= ----- _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf -------------------------------------------------------------------------= ----- Geen virus gevonden in het binnenkomende-bericht. Gecontroleerd door AVG - www.avg.com=20 Versie: 9.0.709 / Virusdatabase: 270.14.80/2523 - datum van uitgifte: = 11/24/09 08:46:00 ------=_NextPart_000_10BE_01CA7E37.E327FC30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
WG participants,
 
no-one objected to the below. So hereby we have = confirmed that=20 the WG
has consensus to work on a rfc4742bis = document.
 
So we (WG chairs) will ask for the milestone updates = to the WG=20 charter page.
 
And Margaret is ready and eager to post the = first draft=20 as a WG document.
 
There was already some discussion on the mailing = list, and=20 hopefully the
initial I-D will cause some more.
 
Bert and Mehmet
----- Original Message -----
From:=20 Bert Wijnen=20 (IETF)
To: Netconf
Sent: Tuesday, November 24, = 2009 10:29=20 PM
Subject: [Netconf] Poll for WG = consensus=20 on doing a rfc4742bis

WG participants,
 
The two  authors/editors of RFC4742 have = agreed to pick=20 up the pen if we
indeed want to produce a RFC4742bis. Maragert will = do the=20 bulk
of the editing though.
 
At the IETF76 meeting we had consensus to do an = RFC4742bis.=20
Our current WG charter allows for this. All we = need to do is=20 add a milestone.
The proposed milestones are:
 
- dec 2009  publish initial wg draft for=20 rfc4742bis
- 1Q 2010   WG Last Call = rfc4742bis
- 2Q 2010   send rfc4742bis to IESG for=20 publication as stdsa track RFC.
 
But we need to confirm this = on the=20 mailing list.
 
So please speak up ASAP, but no later than Dec = 1st, if you=20 feel we should
not undertake that work. We (WG-chairs) will take = silence as=20 agreement this time.
 
Bert & Mehmet

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


Geen virus gevonden in het = binnenkomende-bericht.
Gecontroleerd=20 door AVG - www.avg.com
Versie: 9.0.709 / Virusdatabase: = 270.14.80/2523 -=20 datum van uitgifte: 11/24/09 08:46:00
------=_NextPart_000_10BE_01CA7E37.E327FC30-- From rfc-editor@rfc-editor.org Mon Dec 21 17:36:13 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097573A68E1; Mon, 21 Dec 2009 17:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.242 X-Spam-Level: X-Spam-Status: No, score=-17.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+N2sbPk14BL; Mon, 21 Dec 2009 17:36:12 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 536293A6864; Mon, 21 Dec 2009 17:36:12 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id D0F7C38CC64; Mon, 21 Dec 2009 17:34:51 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091222013451.D0F7C38CC64@bosco.isi.edu> Date: Mon, 21 Dec 2009 17:34:51 -0800 (PST) Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 5717 on Partial Lock Remote Procedure Call (RPC) for NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 01:36:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5717 Title: Partial Lock Remote Procedure Call (RPC) for NETCONF Author: B. Lengyel, M. Bjorklund Status: Standards Track Date: December 2009 Mailbox: balazs.lengyel@ericsson.com, mbj@tail-f.com Pages: 23 Characters: 42529 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-partial-lock-11.txt URL: http://www.rfc-editor.org/rfc/rfc5717.txt The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. [STANDARDS TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From bertietf@bwijnen.net Mon Dec 21 23:41:56 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72D43A697E for ; Mon, 21 Dec 2009 23:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=-1.253, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5QOCa87xJke for ; Mon, 21 Dec 2009 23:41:55 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 97E3D3A6784 for ; Mon, 21 Dec 2009 23:41:54 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NMzN4-0005a0-5q for netconf@ietf.org; Tue, 22 Dec 2009 08:41:35 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id 28F412F583 for ; Tue, 22 Dec 2009 08:41:30 +0100 (CET) Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NMzN3-0007zW-VW for netconf@ietf.org; Tue, 22 Dec 2009 08:41:30 +0100 Message-ID: <4B30782B.2090105@bwijnen.net> Date: Tue, 22 Dec 2009 08:41:31 +0100 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: netconf@ietf.org References: <20091222013451.D0F7C38CC64@bosco.isi.edu> In-Reply-To: <20091222013451.D0F7C38CC64@bosco.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40a5498a33eefbe8d847af00cd9a79a63 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40a5498a33eefbe8d847af00cd9a79a63 Subject: [Netconf] Congratulations and thanks for RFC 5717 on Partial Lock Remote Procedure Call (RPC) for NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 07:41:56 -0000 What a nice Xmas present for our WG. Congratulations. Many/special thanks to Balazs and Martin for their hard work on 11 revisions. Bert rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 5717 > > Title: Partial Lock Remote Procedure Call > (RPC) for NETCONF > Author: B. Lengyel, M. Bjorklund > Status: Standards Track > Date: December 2009 > Mailbox: balazs.lengyel@ericsson.com, > mbj@tail-f.com > Pages: 23 > Characters: 42529 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-netconf-partial-lock-11.txt > > URL: http://www.rfc-editor.org/rfc/rfc5717.txt > > The Network Configuration protocol (NETCONF) defines the lock and > unlock Remote Procedure Calls (RPCs), used to lock entire > configuration datastores. In some situations, a way to lock only > parts of a configuration datastore is required. This document > defines a capability-based extension to the NETCONF protocol for > locking portions of a configuration datastore. [STANDARDS TRACK] > > This document is a product of the Network Configuration Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > From web-usrn@ISI.EDU Mon Dec 28 02:54:07 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11C43A68D5 for ; Mon, 28 Dec 2009 02:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.948 X-Spam-Level: X-Spam-Status: No, score=-16.948 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKTz4+d6sW2r for ; Mon, 28 Dec 2009 02:54:07 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id E92093A6822 for ; Mon, 28 Dec 2009 02:54:06 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSAr8eP012410; Mon, 28 Dec 2009 02:53:09 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSAr5Bd012387; Mon, 28 Dec 2009 02:53:05 -0800 (PST) Date: Mon, 28 Dec 2009 02:53:05 -0800 (PST) Message-Id: <200912281053.nBSAr5Bd012387@boreas.isi.edu> To: balazs.lengyel@ericsson.com, mbj@tail-f.com, dromasca@avaya.com, rbonica@juniper.net, bertietf@bwijnen.net, mehmet.ersue@nsn.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] [Technical Errata Reported] RFC5717 (1978) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 10:54:07 -0000 The following errata report has been submitted for RFC5717, "Partial Lock Remote Procedure Call (RPC) for NETCONF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5717&eid=1978 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: App. A, p.16 Original Text ------------- The content of the reply to a successful partial-lock request MUST conform to this complex type. | Identifies the lock to be released. Must be the value | received in the response to a partial-lock operation. [...] Corrected Text -------------- The content of the reply to a successful partial-lock request MUST conform to this complex type. | Identifies the lock, if granted. This lock-id must | be used in the partial-unlock operation. [...] Notes ----- Rationale: The clause in the RFC apparently has been copied from page 15 (bottom part), where the partialUnLockType is getting defined, without the necessary changes in semantics for the context of the reply to a partial-lock operation. The replacement text has been crafted in the spirit of the corresponding description in the YANG module in Appendix B. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5717 (draft-ietf-netconf-partial-lock-11) -------------------------------------- Title : Partial Lock Remote Procedure Call (RPC) for NETCONF Publication Date : December 2009 Author(s) : B. Lengyel, M. Bjorklund Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From bertietf@bwijnen.net Mon Dec 28 04:30:56 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6CAA3A6870 for ; Mon, 28 Dec 2009 04:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.006 X-Spam-Level: X-Spam-Status: No, score=-0.006 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8toqL3+FoSwj for ; Mon, 28 Dec 2009 04:30:55 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 239173A67A2 for ; Mon, 28 Dec 2009 04:30:54 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1NPEk5-0001I4-Cm; Mon, 28 Dec 2009 13:30:33 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: , References: <200912281053.nBSAr5Bd012387@boreas.isi.edu> In-Reply-To: <200912281053.nBSAr5Bd012387@boreas.isi.edu> Date: Mon, 28 Dec 2009 13:30:04 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_33E3_01CA87C1.DD667E00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Cc: Netconf Subject: Re: [Netconf] [Technical Errata Reported] RFC5717 (1978) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 12:30:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_33E3_01CA87C1.DD667E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Balzs and Martin, it seems to me that Alfred is correct in having found a problem. It also seems that his suggested fix is correct. If you agree, pls confirm on our mailing list, and then we (WG chairs) = will ask our AD to approve the errata and fix. That will then be formally registered on the Errata pages, and you can make the fix in your source .xml files, so that if we ever do a -bis = version that it will be inclued. Bert ----- Original Message -----=20 From: RFC Errata System=20 To: balazs.lengyel@ericsson.com ; mbj@tail-f.com ; dromasca@avaya.com = ; rbonica@juniper.net ; bertietf@bwijnen.net ; mehmet.ersue@nsn.com=20 Cc: ah@TR-Sys.de ; netconf@ietf.org ; rfc-editor@rfc-editor.org=20 Sent: Monday, December 28, 2009 11:53 AM Subject: [Technical Errata Reported] RFC5717 (1978) The following errata report has been submitted for RFC5717, "Partial Lock Remote Procedure Call (RPC) for NETCONF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5717&eid=3D1978 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: App. A, p.16 Original Text ------------- The content of the reply to a successful partial-lock request MUST conform to this complex = type. | Identifies the lock to be released. Must be the = value | received in the response to a partial-lock = operation. [...] Corrected Text -------------- The content of the reply to a successful partial-lock request MUST conform to this complex = type. | Identifies the lock, if granted. This lock-id must | be used in the partial-unlock operation. [...] Notes ----- Rationale: The clause in the RFC apparently has been copied from page 15 (bottom part), where the partialUnLockType is getting defined, without the necessary changes in semantics for the context of the reply to a partial-lock operation. The replacement text has been crafted in the spirit of the corresponding description in the YANG module in Appendix B. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC5717 (draft-ietf-netconf-partial-lock-11) -------------------------------------- Title : Partial Lock Remote Procedure Call (RPC) for = NETCONF Publication Date : December 2009 Author(s) : B. Lengyel, M. Bjorklund Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG -------------------------------------------------------------------------= ----- Geen virus gevonden in het binnenkomende-bericht. Gecontroleerd door AVG - www.avg.com=20 Versie: 9.0.722 / Virusdatabase: 270.14.121/2589 - datum van uitgifte: = 12/27/09 10:18:00 ------=_NextPart_000_33E3_01CA87C1.DD667E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Balzs and Martin,
 
it seems to me that Alfred is correct in having = found a=20 problem.
It also seems that his suggested fix is = correct.
 
If you agree, pls confirm on our mailing list, and = then we (WG=20 chairs) will
ask our AD to approve the errata and = fix.
 
That will then be formally registered on the Errata = pages, and=20 you can
make the fix in your source .xml files, so that if = we ever do=20 a -bis version
that it will be inclued.
 
Bert
 
----- Original Message -----
From:=20 RFC=20 Errata System
To: balazs.lengyel@ericsson.com ; mbj@tail-f.com ; dromasca@avaya.com ; rbonica@juniper.net ; bertietf@bwijnen.net ; mehmet.ersue@nsn.com
Cc: ah@TR-Sys.de ; netconf@ietf.org ; rfc-editor@rfc-editor.org =
Sent: Monday, December 28, 2009 = 11:53=20 AM
Subject: [Technical Errata = Reported]=20 RFC5717 (1978)


The following errata report has been submitted for=20 RFC5717,
"Partial Lock Remote Procedure Call (RPC) for=20 NETCONF".

--------------------------------------
You may = review the=20 report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D5717&eid=3D19= 78

--------------------------------------
Type:=20 Technical
Reported by: Alfred Hoenes <ah@TR-Sys.de>

Section: App. = A,=20 p.16

Original Text
-------------
    = <!-- reply=20 to <partial-lock> -->

    = <xs:complexType=20 = name=3D"contentPartInPartialLockReplyType">
    = ;   =20 = <xs:annotation>
        =    =20 = <xs:documentation>
       &nb= sp;       =20 The content of the reply to a=20 = successful
          = ;     =20 partial-lock request MUST conform to this complex=20 = type.
          &nbs= p;=20 = </xs:documentation>
       =20 </xs:annotation>
       =20 = <xs:sequence>
        &n= bsp;  =20 <xs:element name=3D"lock-id"=20 = type=3D"lock-id-type">
       &n= bsp;     =20 = <xs:annotation>
        =        =20 = <xs:documentation>
|       &n= bsp;        =20 Identifies the lock to be released.  Must be the=20 = value
|          &nb= sp;     =20 received in the response to a partial-lock=20 = operation.
          = ;     =20 = </xs:documentation>
       &n= bsp;     =20 = </xs:annotation>
        = ;   =20 = </xs:element>
        &n= bsp;  =20 [...]

Corrected Text
--------------
    = <!--=20 reply to <partial-lock> -->

   =20 <xs:complexType=20 = name=3D"contentPartInPartialLockReplyType">
    = ;   =20 = <xs:annotation>
        =    =20 = <xs:documentation>
       &nb= sp;       =20 The content of the reply to a=20 = successful
          = ;     =20 partial-lock request MUST conform to this complex=20 = type.
          &nbs= p;=20 = </xs:documentation>
       =20 </xs:annotation>
       =20 = <xs:sequence>
        &n= bsp;  =20 <xs:element name=3D"lock-id"=20 = type=3D"lock-id-type">
       &n= bsp;     =20 = <xs:annotation>
        =        =20 = <xs:documentation>
|       &n= bsp;        =20 Identifies the lock, if granted.  This lock-id=20 = must
|          &nbs= p;     =20 be used in the partial-unlock=20 = operation.
          = ;     =20 = </xs:documentation>
       &n= bsp;     =20 = </xs:annotation>
        = ;   =20 = </xs:element>
        &n= bsp;  =20 [...]

Notes
-----
Rationale:
  The clause in the = RFC=20 apparently has been copied from page 15
  (bottom part), where = the=20 partialUnLockType is getting defined,
  without the necessary = changes=20 in semantics for the context of
  the reply to a partial-lock=20 operation.
  The replacement text has been crafted in the = spirit of=20 the
  corresponding description in the YANG module in Appendix = B.

Instructions:
-------------
This errata is currently = posted as=20 "Reported". If necessary, please
use "Reply All" to discuss whether = it=20 should be verified or
rejected. When a decision is reached, the = verifying=20 party (IESG)
can log in to change the status and edit the report, = if=20 necessary.

--------------------------------------
RFC5717=20 = (draft-ietf-netconf-partial-lock-11)
---------------------------------= -----
Title          = ;    =20 : Partial Lock Remote Procedure Call (RPC) for NETCONF
Publication=20 Date    : December=20 = 2009
Author(s)         &n= bsp;=20 : B. Lengyel, M.=20 = Bjorklund
Category        &nbs= p;  =20 : PROPOSED=20 = STANDARD
Source         &= nbsp;   =20 : Network=20 = Configuration
Area        &nbs= p;      =20 : Operations and=20 = Management
Stream         = ;    =20 : IETF
Verifying Party     : IESG


Geen virus gevonden in het = binnenkomende-bericht.
Gecontroleerd=20 door AVG - www.avg.com
Versie: = 9.0.722 /=20 Virusdatabase: 270.14.121/2589 - datum van uitgifte: 12/27/09=20 10:18:00
------=_NextPart_000_33E3_01CA87C1.DD667E00-- From mbj@tail-f.com Mon Dec 28 04:41:49 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92CC53A695A for ; Mon, 28 Dec 2009 04:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQBrmHg5tK87 for ; Mon, 28 Dec 2009 04:41:49 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C88A53A68AF for ; Mon, 28 Dec 2009 04:41:48 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A4EA476C686; Mon, 28 Dec 2009 13:41:28 +0100 (CET) Date: Mon, 28 Dec 2009 13:41:27 +0100 (CET) Message-Id: <20091228.134127.196030284.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: References: <200912281053.nBSAr5Bd012387@boreas.isi.edu> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC5717 (1978) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 12:41:49 -0000 "Bert Wijnen \(IETF\)" wrote: > Balzs and Martin, > > it seems to me that Alfred is correct in having found a problem. > It also seems that his suggested fix is correct. > > If you agree, pls confirm on our mailing list, and then we (WG chairs) will > ask our AD to approve the errata and fix. I agree, his suggested fix is correct. (The YANG description should be exactly the same as the XSD description as well...) /martin