From bertietf@bwijnen.net Fri Sep 4 02:00: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 0441F3A68C0 for ; Fri, 4 Sep 2009 02:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.758 X-Spam-Level: X-Spam-Status: No, score=-4.758 tagged_above=-999 required=5 tests=[AWL=-2.159, 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 1Qz0s-cmC3x6 for ; Fri, 4 Sep 2009 02:00:45 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 05B063A6843 for ; Fri, 4 Sep 2009 02:00:43 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MjSsC-0004ap-07 for netconf@ietf.org; Fri, 04 Sep 2009 09:06:21 +0200 Received: from guest-116.ripe.net (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id EE8E32F583 for ; Fri, 4 Sep 2009 09:06:15 +0200 (CEST) Message-ID: <4AA0BC67.9020102@bwijnen.net> Date: Fri, 04 Sep 2009 09:06:15 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4c3bd2feb82b29f2ea766cc1a0536a032 Subject: [Netconf] [Fwd: WG chairs affiliation] 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 Sep 2009 09:00:46 -0000 So just in case some people did not hear/know this. Since July 13th 2009 I am employed by RIPE-NCC in the Netherlands. Bert -------- Original Message -------- Subject: WG chairs affiliation Date: Thu, 3 Sep 2009 15:54:38 +0200 From: Romascanu, Dan (Dan) To: The issue below was discussed by the IESG in the last telechat as a management item. Some WGs have more than one co-chair. It is considered a good practice that co-chairs of the same WG are not affiliated or their particpation is not sponsored by the same company. However this is not a mandatory requirement and situations may happen where individuals change affiliation or sponsorship. It is recommended that such cases are made known to the community and especially to the other WG participants. For this purpose ADs will recommend the chairs of the WGs to disclose their affiliation or participation sponsorship at nomination and in cases of changes of affiliation or sponsorship - especially when these are not obvious from their email addresses - by sending a message to the WG mail list. Dan From bertietf@bwijnen.net Wed Sep 9 08:56: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 56F6728C426 for ; Wed, 9 Sep 2009 08:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077] 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 X3UQpApuP98p for ; Wed, 9 Sep 2009 08:56:29 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 930CB28C41A for ; Wed, 9 Sep 2009 08:56:29 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MlPXU-0001DU-5C for netconf@ietf.org; Wed, 09 Sep 2009 17:57:01 +0200 Received: from BWMACBOOK.local (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 1499D2F583 for ; Wed, 9 Sep 2009 17:56:56 +0200 (CEST) Message-ID: <4AA7D047.1060607@bwijnen.net> Date: Wed, 09 Sep 2009 17:56:55 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd49142f0260bd6b8fc2a3cec9462d8f7bc Subject: [Netconf] NOMCOM 2009-2010] 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 Sep 2009 15:56:30 -0000 Hi, the NOMCOM Call for Nominations is still open and the NOMCOM likes to see more nominations. Please consider volunteering if you want to make a leadership contribution to the IETF. There details are here: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06510.html Bert and Mehmet From MARKSCOT@nortel.com Wed Sep 16 11:41: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 897733A6A08; Wed, 16 Sep 2009 11:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=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 ec5716KunfNX; Wed, 16 Sep 2009 11:41:04 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 990513A68D7; Wed, 16 Sep 2009 11:41:03 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n8GIfG121574; Wed, 16 Sep 2009 18:41:16 GMT 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, 16 Sep 2009 14:41:13 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1A5B2410@zcarhxm0.corp.nortel.com> In-Reply-To: <4A7EF28E.2040502@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] staying in synch on data model discovery Thread-Index: AcoZClgw5YEVpa1TRmib019DCr8bdAd67s/Q References: <4A7EF28E.2040502@netconfcentral.com> From: "Mark Scott" To: "Andy Bierman" , "NETMOD Working Group" , "NETCONF" Subject: Re: [Netconf] [netmod] staying in synch on data model discovery 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 Sep 2009 18:41:07 -0000 Andy, Pardon my delayed response on this. To address your points below. 1. NETCONF and NETMOD collaboration: per WG consensus we have updated the monitoring draft to use YANG as the normative data model. I won't speak for other NETCONF drafts but this is a positive step for this one. 2. mandatory parameters: Initially was the only mandatory parameter in the operation, however after we agreed to expand the key definition in the schema list we made and mandatory parameters in the operation. My preference would be to keep this alignment between the key and mandatory parms. I agree in cases where only 1 revision and/or 1 format exists this is heavy-handed but it protects against agents returning schema a manager may not have intended since is not unique in schema list and the logic on agent to select the default revision may differ from what the manager would have selected (esp. if more than 1 version exists). 3. Agree on the benefit of this and will add it to latest version which we will be posting shortly. Mark -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Sunday, August 09, 2009 12:00 PM To: NETMOD Working Group; NETCONF Subject: [netmod] staying in synch on data model discovery Hi, I would like to see the NETCONF and NETMOD WGs act more like they play for the same team regarding YANG and all the YANG data models under development. I mostly care about the ietf-netconf-state data model to use the get-schema() operation with YANG. If others want XSD and RNG instead, then that's extra credit, but full support for YANG is a must-have. YANG modules, submodules, and deviation modules all need to be listed in the and retrievable with . However, deviations have no revision that is advertised, yet they clearly have a revision-date just like any other YANG module. This is somewhere between confusing and broken. The field in the operation is mandatory. It should be optional, and if missing, then the agent will pick whatever revision it wants (usually there will just be 1 to pick from). The field in the operation is mandatory. It should be optional, and the default should be 'YANG'. IMO, the use of capabilities instead of YANG features needs to stop. Even more, ALL the data models under way in the NETCONF WG should wait for YANG, and use YANG features, not protocol capabilities to achieve. That will eliminate the possibility that there can be 16 valid variants of the same leaf,and will help start out with a coherent set of YANG modules using the same data types (e.g., ip-address issue). I think the node should have another leaf: leaf moduleType { description "The type of data model file for this schema entry."; type enumeration { enum module { description "Indicates this entry is for a main module."; } enum submodule { description "Indicates this entry is for a sub-module."; } enum deviation { description "Indicates this entry is for a deviation module."; } enum other { description "Indicates this entry is for some other type of module."; } } } This will help operators understand what all the 'extra' entries are for, and allow better filtering of the subtree. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From MARKSCOT@nortel.com Wed Sep 16 13:52: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 B18B03A6A18; Wed, 16 Sep 2009 13:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=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 48dpkeY+uEG7; Wed, 16 Sep 2009 13:52:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 727E23A6ADA; Wed, 16 Sep 2009 13:52:43 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n8GKqv111913; Wed, 16 Sep 2009 20:52:57 GMT 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, 16 Sep 2009 16:52:55 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1A5B2674@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D1A5B2410@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [netmod] staying in synch on data model discovery Thread-Index: AcoZClgw5YEVpa1TRmib019DCr8bdAd67s/QAAZGGcA= References: <4A7EF28E.2040502@netconfcentral.com> <085091CB2CA14E4B8B163FFC37C84E9D1A5B2410@zcarhxm0.corp.nortel.com> From: "Mark Scott" To: "Andy Bierman" , "NETMOD Working Group" , "NETCONF" Subject: Re: [Netconf] [netmod] staying in synch on data model discovery 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 Sep 2009 20:52:44 -0000 Andy (and Martin), While updating the YANG module for point 3 below I wonder instead of enumeration do we want to make this an identityref? =20 Similar to what we did for schema-format to allow extensibility and allows non-YANG formats to use something more meaningful the moduleType=3D'other'. Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Scott, Mark (CAR:2N00) Sent: Wednesday, September 16, 2009 2:41 PM To: Andy Bierman; NETMOD Working Group; NETCONF Subject: Re: [Netconf] [netmod] staying in synch on data model discovery Andy, Pardon my delayed response on this. To address your points below. 1. NETCONF and NETMOD collaboration: per WG consensus we have updated the monitoring draft to use YANG as the normative data model. I won't speak for other NETCONF drafts but this is a positive step for this one. 2. mandatory parameters: Initially was the only mandatory parameter in the operation, however after we agreed to expand the key definition in the schema list we made and mandatory parameters in the operation. My preference would be to keep this alignment between the key and mandatory parms. I agree in cases where only 1 revision and/or 1 format exists this is heavy-handed but it protects against agents returning schema a manager may not have intended since is not unique in schema list and the logic on agent to select the default revision may differ from what the manager would have selected (esp. if more than 1 version exists). 3. Agree on the benefit of this and will add it to latest version which we will be posting shortly. Mark -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Sunday, August 09, 2009 12:00 PM To: NETMOD Working Group; NETCONF Subject: [netmod] staying in synch on data model discovery Hi, I would like to see the NETCONF and NETMOD WGs act more like they play for the same team regarding YANG and all the YANG data models under development. I mostly care about the ietf-netconf-state data model to use the get-schema() operation with YANG. If others want XSD and RNG instead, then that's extra credit, but full support for YANG is a must-have. YANG modules, submodules, and deviation modules all need to be listed in the and retrievable with . However, deviations have no revision that is advertised, yet they clearly have a revision-date just like any other YANG module. This is somewhere between confusing and broken. The field in the operation is mandatory. It should be optional, and if missing, then the agent will pick whatever revision it wants (usually there will just be 1 to pick from). The field in the operation is mandatory. It should be optional, and the default should be 'YANG'. IMO, the use of capabilities instead of YANG features needs to stop. Even more, ALL the data models under way in the NETCONF WG should wait for YANG, and use YANG features, not protocol capabilities to achieve. That will eliminate the possibility that there can be 16 valid variants of the same leaf,and will help start out with a coherent set of YANG modules using the same data types (e.g., ip-address issue). I think the node should have another leaf: leaf moduleType { description "The type of data model file for this schema entry."; type enumeration { enum module { description "Indicates this entry is for a main module."; } enum submodule { description "Indicates this entry is for a sub-module."; } enum deviation { description "Indicates this entry is for a deviation module."; } enum other { description "Indicates this entry is for some other type of module."; } } } This will help operators understand what all the 'extra' entries are for, and allow better filtering of the subtree. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From andy@netconfcentral.com Fri Sep 18 09:44: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 E0B2D3A6A14 for ; Fri, 18 Sep 2009 09:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.416 X-Spam-Level: X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_29=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 MN+n0NGzVpHu for ; Fri, 18 Sep 2009 09:44:48 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id 1933228C198 for ; Fri, 18 Sep 2009 09:44:48 -0700 (PDT) Received: from [209.191.108.97] by n20.bullet.mail.mud.yahoo.com with NNFMP; 18 Sep 2009 16:45:41 -0000 Received: from [68.142.201.240] by t4.bullet.mud.yahoo.com with NNFMP; 18 Sep 2009 16:45:41 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 18 Sep 2009 16:45:41 -0000 X-Yahoo-Newman-Id: 109241.75168.bm@omp401.mail.mud.yahoo.com Received: (qmail 32574 invoked from network); 18 Sep 2009 16:45:40 -0000 Received: from adsl-67-126-128-122.dsl.irvnca.pacbell.net (andy@67.126.128.122 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 18 Sep 2009 09:45:40 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: DoTGziQVM1nNwH7K9sIDef36tkMwmK0qP3x1saw18RJ7sMtLKMH6FSEtPGusO3WCunQWPljefJtfrATHRR3Pd.FWISP1AOMNYbn54y0GV5h87mWMbXHguoYQkiW6IZw61U_RdxSj6ZLze3UzVledFyIDHrs.0MQjyZenp.4eUXLfREky63WGekNwZ.p4m7YFOIkpzSmgqqvD48.upFe_h4oX.yX7XxKV2i8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AB3B937.6050006@netconfcentral.com> Date: Fri, 18 Sep 2009 09:45:43 -0700 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] :test-only-1.0 instead of :validate-1.1 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, 18 Sep 2009 16:44:49 -0000 Hi, I think the still needs work, and Balazs also raised issues about it. All but 2 issues are either resolved or don't-care: 1) the client should be able to use 'test-only' in edit-config, even if :validate-1.0 is not supported 2) the client is not allowed to provide any leaf at all if :validate-1.0 is not supported. I think we should consider a :test-option-1.0 capability, instead of a :validate-1.1 capability: If the :test-only capability is advertised, it means the server will accept the new parameter to edit-config. (See below.) It preserved validate-1.0 for the clients that rely on it, and decouples the new functionality. The validate-1.0 capability would remain unchanged. A new 'test-only' feature would be added to match the new :test-only capability. The edit-config/input section would be modified as follows: choice edit-config-test-option { if-feature validate; if-feature test-only; leaf test-option { if-feature validate; // rest same as RFC 4741 } leaf test-only { if-feature test-only; type empty; description "The server will perform all the validation procedures for the requested operation, except no changes will be made to the specified target database."; } } I think this is cleaner than :validate-1.1. The concept of 'validation' in NETCONF is server-specific, and probably of little standards value, but there is still operational value in a 'test-only' mode on each server. There is no other way to validate a partial configuration against an existing database. The 'test-only' mode will validate a specific edit-config operation, which must account for arbitrarily nested nc:operation attributes. It allows clients to ask "will this edit work?", which is currently not possible in NETCONF. Andy From andy@netconfcentral.com Mon Sep 21 11:32:25 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 962FD28C19B for ; Mon, 21 Sep 2009 11:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_40=-0.185, 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 onQQxUJYn9L4 for ; Mon, 21 Sep 2009 11:32:24 -0700 (PDT) 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 DD7593A6825 for ; Mon, 21 Sep 2009 11:32:24 -0700 (PDT) Received: (qmail 85725 invoked from network); 21 Sep 2009 18:33:24 -0000 Received: from adsl-67-126-128-122.dsl.irvnca.pacbell.net (andy@67.126.128.122 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 21 Sep 2009 11:33:24 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: moGnY5UVM1kqKCoPXf58IyLbL50gHez1D5frC3wF2B7ZpMmLFQ7uL0Y29u3kXuA6GK3DyUbTKDbwopYy2zNFT9vVumtr2WWRaWvFhjwogpNFqRiWed2O3Fch9Q.IwRyS6LwHoYDXNT3jHa17FJWGFGA_qV0cKv0F6FI3_RaCkfizMXXOaEyZ1Fx6xeg9AXgediE.APcC3SGWmjI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AB7C707.4040305@netconfcentral.com> Date: Mon, 21 Sep 2009 11:33:43 -0700 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, sec. 8.4.1 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, 21 Sep 2009 18:32:25 -0000 Hi, It is clear how the 'shared' aspect of confirmed-commit works without locking. I am still unclear on at least 3 points in 8.4.1: 1 - Does each new confirming-commit to extend the timer (i.e., included in the 2nd to Nth ) reset the saved config that will be used to rollback if needed? The 'revert' text says 'the' confirmed commit, but there can be more than one of these, right? Or is the first commit the confirmed-commit, and all others are the confirming-commit, even if they do nothing but extend the timer? 2 - There is nothing in the NETCONF protocol to support the sentence below: Thus to cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the confirmed commit was issued. The only standard way to do this is to terminate the 'magic' session that triggers the rollback sequence. 3- If the candidate and/or running was not locked by the original session that issued the first confirmed-commit, but one or both is locked by another session before the confirmed-commit finishes: - the original session is now incapable of issuing commit because running and/or candidate is locked. - if the confirmed-commit times out or the originator's session is terminated, then 1 of 2 'rules' cannot be honored (A or B must be true, but not both): outcome A) the lock fails and the rollback works: rollback prevents the lock semantics from being honored outcome B) the lock works and the rollback fails: lock prevents the semantics of :confirmed-commit from being honored Is there any consensus that any text in 8.4.1 needs to be altered, or are these 'server free to decide' issues? Andy From mbj@tail-f.com Mon Sep 21 13:55: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 C36283A68CD for ; Mon, 21 Sep 2009 13:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 oGeTNhMPDvNU for ; Mon, 21 Sep 2009 13:55:02 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 926013A6989 for ; Mon, 21 Sep 2009 13:55:02 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 407C476C61C; Mon, 21 Sep 2009 22:56:02 +0200 (CEST) Date: Mon, 21 Sep 2009 22:56:02 +0200 (CEST) Message-Id: <20090921.225602.67828409.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AB7C707.4040305@netconfcentral.com> References: <4AB7C707.4040305@netconfcentral.com> X-Mailer: Mew version 6.0.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, sec. 8.4.1 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, 21 Sep 2009 20:55:03 -0000 Andy Bierman wrote: > Hi, > > It is clear how the 'shared' aspect of confirmed-commit > works without locking. > > I am still unclear on at least 3 points in 8.4.1: > > > > 1 - Does each new confirming-commit to extend the timer > (i.e., included in the 2nd to Nth ) > reset the saved config that will be used to rollback > if needed? > > The 'revert' text says 'the' confirmed commit, but there > can be more than one of these, right? Or is the first commit > the confirmed-commit, and all others are the confirming-commit, > even if they do nothing but extend the timer? I agree that this needs to be clarified. I'm sure different people have interpreted this text differently. I thought the second confirming-commit does not reset the saved config, i.e. each additional confirming-commit would just extend the timer, but I don't know if this was the original intention. > 2 - There is nothing in the NETCONF protocol to support the sentence below: > > Thus to cancel a confirmed commit and revert > changes without waiting for the confirm timeout to expire, the client > can explicitly restore the configuration to its state before the > confirmed commit was issued. > > The only standard way to do this is to terminate the 'magic' session > that triggers the rollback sequence. Yes, I think this text should be removed, or if we do a confirmed-commit:1.1 we can clarify this text. > 3- If the candidate and/or running was not locked by the original > session that issued the first confirmed-commit, but one or both > is locked by another session before the confirmed-commit finishes: > > - the original session is now incapable of issuing commit > because running and/or candidate is locked. > > - if the confirmed-commit times out or the > originator's session is terminated, then 1 of 2 'rules' > cannot be honored (A or B must be true, but not both): > > outcome A) the lock fails and the rollback works: > rollback prevents the lock semantics > from being honored > > outcome B) the lock works and the rollback fails: > lock prevents the semantics of :confirmed-commit > from being honored > > > Is there any consensus that any text in 8.4.1 needs to be altered, > or are these 'server free to decide' issues? This must be fixed. There is actually a trac ticket for this issue (http://trac.tools.ietf.org/wg/netconf/trac/ticket/17), and it was brought up by Balazs on the ML (http://www.ietf.org/mail-archive/web/netconf/current/msg02753.html). /martin From andy@netconfcentral.com Mon Sep 21 15:28: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 B58373A6B2B for ; Mon, 21 Sep 2009 15:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.424, 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 96NjT87xuV37 for ; Mon, 21 Sep 2009 15:28:45 -0700 (PDT) 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 81E6A3A6B17 for ; Mon, 21 Sep 2009 15:28:43 -0700 (PDT) Received: (qmail 79413 invoked from network); 21 Sep 2009 22:29:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.126.128.122 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 21 Sep 2009 22:29:43 -0000 X-YMail-OSG: shb91REVM1n56kXonRNIfyYh2TcH34Dw_6WhMmsdmbYc3oEKgMmaQcm79Ps.C.eI.GNlzf25XP3lb.jI5jpDpno7GdnqL3GmxJmDDidR64UJ0.1h5_6YLymsrZZx_Do77CmU1q4w3vlbr2LOY03Xx0nhM_fiWqf8okEjaf_m5IzzeWmMI9SO5YZp8xVx_gLuoQCvIWOgOFkkor.hOtzx1xmNBCvcc3nqvgXN8TI7R_JQ1NHmYy_jaR01ZCA7E_So.8bNKPG0UPVWM5WuqtCNEpZVxxNoVIEqCfLvZAqMax8NDuTP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AB7FE6B.9020007@netconfcentral.com> Date: Mon, 21 Sep 2009 15:30:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4AB7C707.4040305@netconfcentral.com> <20090921.225602.67828409.mbj@tail-f.com> In-Reply-To: <20090921.225602.67828409.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, sec. 8.4.1 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, 21 Sep 2009 22:28:46 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> It is clear how the 'shared' aspect of confirmed-commit >> works without locking. >> >> I am still unclear on at least 3 points in 8.4.1: >> >> >> >> 1 - Does each new confirming-commit to extend the timer >> (i.e., included in the 2nd to Nth ) >> reset the saved config that will be used to rollback >> if needed? >> >> The 'revert' text says 'the' confirmed commit, but there >> can be more than one of these, right? Or is the first commit >> the confirmed-commit, and all others are the confirming-commit, >> even if they do nothing but extend the timer? > > I agree that this needs to be clarified. I'm sure different people > have interpreted this text differently. I thought the second > confirming-commit does not reset the saved config, i.e. each > additional confirming-commit would just extend the timer, but I don't > know if this was the original intention. I don't remember any discussion on it. I interpret it to mean only the first commit saves the backup-copy. As each new edit-candidate+confirmed-commit extends the timer and alters running, the non-original edits are going to get zapped along with all the others. > >> 2 - There is nothing in the NETCONF protocol to support the sentence below: >> >> Thus to cancel a confirmed commit and revert >> changes without waiting for the confirm timeout to expire, the client >> can explicitly restore the configuration to its state before the >> confirmed commit was issued. >> >> The only standard way to do this is to terminate the 'magic' session >> that triggers the rollback sequence. > > Yes, I think this text should be removed, or if we do a > confirmed-commit:1.1 we can clarify this text. > It should say s/restore the configuration/restore the configuration by terminating the session/ >> 3- If the candidate and/or running was not locked by the original >> session that issued the first confirmed-commit, but one or both >> is locked by another session before the confirmed-commit finishes: >> >> - the original session is now incapable of issuing commit >> because running and/or candidate is locked. >> >> - if the confirmed-commit times out or the >> originator's session is terminated, then 1 of 2 'rules' >> cannot be honored (A or B must be true, but not both): >> >> outcome A) the lock fails and the rollback works: >> rollback prevents the lock semantics >> from being honored >> >> outcome B) the lock works and the rollback fails: >> lock prevents the semantics of :confirmed-commit >> from being honored >> >> >> Is there any consensus that any text in 8.4.1 needs to be altered, >> or are these 'server free to decide' issues? > > This must be fixed. There is actually a trac ticket for this > issue (http://trac.tools.ietf.org/wg/netconf/trac/ticket/17), and it > was brought up by Balazs on the ML > (http://www.ietf.org/mail-archive/web/netconf/current/msg02753.html). > Well, denying the lock request seems bad because the original user ignored locks. He is the one who should get stomped on. IMO, the lock should be honored and the rollback should fail. Another issue is warnings//notifications. IMO, a event would help, with a (started, canceled, finished) status enum. It doesn't seem like we will ever use warnings, because and can never appear together. At least a notification gives some warning that config-clobbering mode is active. > > /martin > Andy From Washam.Fan@huaweisymantec.com Mon Sep 21 22:27: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 197813A68DC for ; Mon, 21 Sep 2009 22:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=0.145, 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 Nnlq2L4AgFq3 for ; Mon, 21 Sep 2009 22:27:00 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 3BF513A6831 for ; Mon, 21 Sep 2009 22:27:00 -0700 (PDT) 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 <0KQC00NH6XTH3E80@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 22 Sep 2009 13:27:17 +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 <0KQC00IOVXTHJ410@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 22 Sep 2009 13:27:17 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 22 Sep 2009 13:27:17 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 22 Sep 2009 13:27:17 +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: <4AB7FE6B.9020007@netconfcentral.com> References: <4AB7C707.4040305@netconfcentral.com> <20090921.225602.67828409.mbj@tail-f.com> <4AB7FE6B.9020007@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, sec. 8.4.1 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 Sep 2009 05:27:01 -0000 Hi, > >> 3- If the candidate and/or running was not locked by the original > >> session that issued the first confirmed-commit, but one or both > >> is locked by another session before the confirmed-commit finishes: > >> > >> - the original session is now incapable of issuing commit > >> because running and/or candidate is locked. > >> > >> - if the confirmed-commit times out or the > >> originator's session is terminated, then 1 of 2 'rules' > >> cannot be honored (A or B must be true, but not both): > >> > >> outcome A) the lock fails and the rollback works: > >> rollback prevents the lock semantics > >> from being honored > >> > >> outcome B) the lock works and the rollback fails: > >> lock prevents the semantics of :confirmed-commit > >> from being honored > >> > >> > >> Is there any consensus that any text in 8.4.1 needs to be altered, > >> or are these 'server free to decide' issues? > > > > This must be fixed. There is actually a trac ticket for this > > issue (http://trac.tools.ietf.org/wg/netconf/trac/ticket/17), and it > > was brought up by Balazs on the ML > > (http://www.ietf.org/mail-archive/web/netconf/current/msg02753.html). > > > > Well, denying the lock request seems bad because the original user > ignored locks. He is the one who should get stomped on. > IMO, the lock should be honored and the rollback should fail. I agree that lock requested by another session should be honored, as didn't imply lock acquisition automatically. But I think some text like below could be added: It is RECOMMENDED that grab a lock before if there might be a potential interruption later. washam > Another issue is warnings//notifications. > IMO, a event would help, > with a (started, canceled, finished) status enum. > It doesn't seem like we will ever use warnings, > because and can never appear together. > At least a notification gives some warning that config-clobbering > mode is active. > > > > > > /martin > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From MARKSCOT@nortel.com Tue Sep 22 07:57:15 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 241F63A6988 for ; Tue, 22 Sep 2009 07:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=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 R8qVIVKx0l0T for ; Tue, 22 Sep 2009 07:57:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id ACFE73A6A21 for ; Tue, 22 Sep 2009 07:57:13 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n8MEveh22193; Tue, 22 Sep 2009 14:57:40 GMT 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, 22 Sep 2009 10:57:39 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1A695296@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D1A5B2674@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] [Netconf] staying in synch on data model discovery Thread-Index: AcoZClgw5YEVpa1TRmib019DCr8bdAd67s/QAAZGGcABIOj7kA== References: <4A7EF28E.2040502@netconfcentral.com><085091CB2CA14E4B8B163FFC37C84E9D1A5B2410@zcarhxm0.corp.nortel.com> <085091CB2CA14E4B8B163FFC37C84E9D1A5B2674@zcarhxm0.corp.nortel.com> From: "Mark Scott" To: "Andy Bierman" Cc: NETCONF Subject: Re: [Netconf] [netmod] staying in synch on data model discovery 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 Sep 2009 14:57:15 -0000 Andy, After some discussion with Martin on #3 below once you exclude 'deviation' (not a valid type) and considering 'other' is non-deterministic we seem to be left with only module and sub-module. As such we don't think this adds much value beyond what you can derive from the format value. So we suggest this not be added to this draft at this time. Based on your description below perhaps this is more of a suggestion to add new module types to YANG and is better suited to the netmod ML for discussion? - Note: I did not cc: this response to netmod ML Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Scott, Mark (CAR:2N00) Sent: Wednesday, September 16, 2009 2:41 PM To: Andy Bierman; NETMOD Working Group; NETCONF Subject: Re: [Netconf] [netmod] staying in synch on data model discovery Andy, Pardon my delayed response on this. To address your points below. 1. NETCONF and NETMOD collaboration: per WG consensus we have updated the monitoring draft to use YANG as the normative data model. I won't speak for other NETCONF drafts but this is a positive step for this one. 2. mandatory parameters: Initially was the only mandatory parameter in the operation, however after we agreed to expand the key definition in the schema list we made and mandatory parameters in the operation. My preference would be to keep this alignment between the key and mandatory parms. I agree in cases where only 1 revision and/or 1 format exists this is heavy-handed but it protects against agents returning schema a manager may not have intended since is not unique in schema list and the logic on agent to select the default revision may differ from what the manager would have selected (esp. if more than 1 version exists). 3. Agree on the benefit of this and will add it to latest version which we will be posting shortly. Mark -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Sunday, August 09, 2009 12:00 PM To: NETMOD Working Group; NETCONF Subject: [netmod] staying in synch on data model discovery Hi, I would like to see the NETCONF and NETMOD WGs act more like they play for the same team regarding YANG and all the YANG data models under development. I mostly care about the ietf-netconf-state data model to use the get-schema() operation with YANG. If others want XSD and RNG instead, then that's extra credit, but full support for YANG is a must-have. YANG modules, submodules, and deviation modules all need to be listed in the and retrievable with . However, deviations have no revision that is advertised, yet they clearly have a revision-date just like any other YANG module. This is somewhere between confusing and broken. The field in the operation is mandatory. It should be optional, and if missing, then the agent will pick whatever revision it wants (usually there will just be 1 to pick from). The field in the operation is mandatory. It should be optional, and the default should be 'YANG'. IMO, the use of capabilities instead of YANG features needs to stop. Even more, ALL the data models under way in the NETCONF WG should wait for YANG, and use YANG features, not protocol capabilities to achieve. That will eliminate the possibility that there can be 16 valid variants of the same leaf,and will help start out with a coherent set of YANG modules using the same data types (e.g., ip-address issue). I think the node should have another leaf: leaf moduleType { description "The type of data model file for this schema entry."; type enumeration { enum module { description "Indicates this entry is for a main module."; } enum submodule { description "Indicates this entry is for a sub-module."; } enum deviation { description "Indicates this entry is for a deviation module."; } enum other { description "Indicates this entry is for some other type of module."; } } } This will help operators understand what all the 'extra' entries are for, and allow better filtering of the subtree. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From andy@netconfcentral.com Tue Sep 22 08:22: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 4248E28C12C for ; Tue, 22 Sep 2009 08:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=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 EIghZML2DbIP for ; Tue, 22 Sep 2009 08:22:02 -0700 (PDT) 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 9754828C11D for ; Tue, 22 Sep 2009 08:22:02 -0700 (PDT) Received: (qmail 51019 invoked from network); 22 Sep 2009 15:23:04 -0000 Received: from adsl-67-126-128-122.dsl.irvnca.pacbell.net (andy@67.126.128.122 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 22 Sep 2009 08:23:03 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: _LSfjrYVM1mowaj51NUFBWzFtCQoimsEIo25iSJFdUvMV.CAPcGtHYa2umh07pICJZRBn6oKF8o9FioIWps1tRx7I6qrqZDNQDAgWwLonNgKK.VshJ4CNH6NLlidUK9JVZxjFhtbsLk56DaNZO1S1LXJoW.POcKe8R3KPUsFSO2.PE1wUTdTVKOPt0JKsxbeeaFVzDIPg2pHRC0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AB8EBF0.3010508@netconfcentral.com> Date: Tue, 22 Sep 2009 08:23:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mark Scott References: <4A7EF28E.2040502@netconfcentral.com><085091CB2CA14E4B8B163FFC37C84E9D1A5B2410@zcarhxm0.corp.nortel.com> <085091CB2CA14E4B8B163FFC37C84E9D1A5B2674@zcarhxm0.corp.nortel.com> <085091CB2CA14E4B8B163FFC37C84E9D1A695296@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D1A695296@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] [netmod] staying in synch on data model discovery 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 Sep 2009 15:22:03 -0000 Mark Scott wrote: > Andy, > > After some discussion with Martin on #3 below once you exclude > 'deviation' (not a valid type) and considering 'other' is > non-deterministic we seem to be left with only module and sub-module. > As such we don't think this adds much value beyond what you can derive > from the format value. So we suggest this not be added to this draft at > this time. > > Based on your description below perhaps this is more of a suggestion to > add new module types to YANG and is better suited to the netmod ML for > discussion? > - Note: I did not cc: this response to netmod ML > Martin is correct that there is no distinction in YANG between different types of modules, so a 'deviation module' is not needed. I thought this issue was closed. No need for this 'moduleType' parameter. The YANG module capability URI doesn't support sub-modules, so is the only way for a client to know for sure that the 'include bar;' in [sub]module foo.yang is really the bar.yang that the server is using. But lots of NETCONF/YANG is pure guesswork on the part of the client, so this is by no means the exception. > Mark Andy From david.partain@ericsson.com Wed Sep 23 14:00: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 809F03A688D; Wed, 23 Sep 2009 14:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.500, 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 1FtpxLymUNDz; Wed, 23 Sep 2009 14:00:07 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EE8463A6819; Wed, 23 Sep 2009 14:00:06 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-71-4aba8c98ba3e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 28.D6.15624.89C8ABA4; Wed, 23 Sep 2009 23:01:12 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 23:00:13 +0200 Received: from [153.88.44.75] ([153.88.44.75]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 23:00:12 +0200 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: NETMOD Working Group , NETCONF Date: Wed, 23 Sep 2009 23:00:15 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909232300.15671.david.partain@ericsson.com> X-OriginalArrivalTime: 23 Sep 2009 21:00:12.0934 (UTC) FILETIME=[D7F11A60:01CA3C90] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Information about a phone call tomorrow (Thursday) 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, 23 Sep 2009 21:00:08 -0000 Greetings, I apologize for the cross-posting, but it seems necessary in this case. The chairs of NETCONF and NETMOD are trying to find a good way forward from the current discussions around default handling in NETCONF and NETMOD. In order for us (the chairs) to understand what the issues are, we've asked some of the primary participants if they'd be join a conference call to help us understand the issues better. This call will take place tomorrow (Thursday, Sep 24) for two hours from 22:00 CET (16:00 East Coast U.S., 13:00 West Coast U.S.). This is _not_ an "interim" of any kind, simply the chairs trying to get input. No decisions will be taken during the meeting. Any suggestions that might come out of the discussions will be published, discussed, and decided upon on the NETCONF and NETMOD mailing lists, of course. The issue at hand is default handling, which some think is broken and others do not. We as chairs need to determine if there is any common ground so we can move on. Others are welcome to participate in the meeting. If you want to call in, please contact me in advance of the meeting. Two things about the meeting: 1. Prior to the meeting (please...), we would like each participant to write a short message to the four of us giving us your take on the situation. As you see it, what are the issues where there is disagreement? If you have concrete suggestions about what you think should be done to fix it, that's good, too. 2. All participants SHOULD be connected to jabber. We're going to use it for floor control. We will use the NETMOD jabber room: Server: jabber.ietf.org Room: netmod The moderator will call on people who "raise their hand" in jabber. Otherwise, the call may be too chaotic to be helpful. If you cannot use jabber, let me know. Please let me know if you want to participate. Cheers, David, on behalf of NETMOD and NETMOD chairs From kwatsen@juniper.net Thu Sep 24 17:01: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 075CA3A6A0E for ; Thu, 24 Sep 2009 17:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 0pczLvV0QjQq for ; Thu, 24 Sep 2009 17:01:38 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 1C2F73A69C8 for ; Thu, 24 Sep 2009 17:01:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSrwIpzPp+nlAPduvdhT/P6cdpdxcv4TP@postini.com; Thu, 24 Sep 2009 17:02:48 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 24 Sep 2009 17:01:28 -0700 From: Kent Watsen To: NETCONF WG Date: Thu, 24 Sep 2009 17:01:28 -0700 Thread-Topic: [Netconf] review of draft-ietf-netconf-with-defaults-03 Thread-Index: AcoheOyJoyjk9+s9Rxe844WHN7rj/Qb9dmig Message-ID: <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> References: <1250760650.23073.3.camel@missotis> In-Reply-To: <1250760650.23073.3.camel@missotis> 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: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 00:01:39 -0000 Hi All, My primary comment is that, when using "report-all", the client has no way = of knowing which values were explicitly set without also getting the "expli= cit" config, which would be a waste of bandwidth... A simple fix to this is to have "report-all" mark the default nodes with an= attribute indicating just that. For instance: 1500 This approach not only resolves the issue mentioned above, but it also allo= ws the output to be fed directly back into an operation witho= ut worries of the device creating a bunch of user-defined nodes in the conf= ig tree What do you think? Thanks, Kent From lhotka@cesnet.cz Fri Sep 25 00:37: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 9A69928C10E for ; Fri, 25 Sep 2009 00:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, 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 SNnMib0F27o7 for ; Fri, 25 Sep 2009 00:37:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D4CD63A67F0 for ; Fri, 25 Sep 2009 00:37:23 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2CBBBD800C1; Fri, 25 Sep 2009 09:38:33 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen In-Reply-To: <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 25 Sep 2009 09:38:32 +0200 Message-Id: <1253864312.11615.4.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETCONF WG Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 07:37:24 -0000 Kent Watsen píše v Čt 24. 09. 2009 v 17:01 -0700: > Hi All, > > My primary comment is that, when using "report-all", the client has no > way of knowing which values were explicitly set without also getting > the "explicit" config, which would be a waste of bandwidth... Is this something that the client has to care about? In my view, it is sufficient to know that a certain value is there. Lada > > A simple fix to this is to have "report-all" mark the default nodes with an attribute indicating just that. For instance: > > 1500 > > This approach not only resolves the issue mentioned above, but it also allows the output to be fed directly back into an operation without worries of the device creating a bunch of user-defined nodes in the config tree > > What do you think? > > Thanks, > Kent > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Sep 25 01:00: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 54E403A67F0 for ; Fri, 25 Sep 2009 01:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 2Zqro0EKYOL4 for ; Fri, 25 Sep 2009 01:00:29 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6A3223A67AC for ; Fri, 25 Sep 2009 01:00:29 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1488776C60A; Fri, 25 Sep 2009 10:01:39 +0200 (CEST) Date: Fri, 25 Sep 2009 10:01:38 +0200 (CEST) Message-Id: <20090925.100138.112555560.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1253864312.11615.4.camel@missotis> References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> <1253864312.11615.4.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 08:00:30 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gS2VudCBXYXRzZW4g cMOtxaFlIHYgxIx0IDI0LiAwOS4gMjAwOSB2IDE3OjAxIC0wNzAwOg0KPiA+IEhpIEFsbCwNCj4g PiANCj4gPiBNeSBwcmltYXJ5IGNvbW1lbnQgaXMgdGhhdCwgd2hlbiB1c2luZyAicmVwb3J0LWFs bCIsIHRoZSBjbGllbnQgaGFzIG5vDQo+ID4gd2F5IG9mIGtub3dpbmcgd2hpY2ggdmFsdWVzIHdl cmUgZXhwbGljaXRseSBzZXQgd2l0aG91dCBhbHNvIGdldHRpbmcNCj4gPiB0aGUgImV4cGxpY2l0 IiBjb25maWcsIHdoaWNoIHdvdWxkIGJlIGEgd2FzdGUgb2YgYmFuZHdpZHRoLi4uDQo+IA0KPiBJ cyB0aGlzIHNvbWV0aGluZyB0aGF0IHRoZSBjbGllbnQgaGFzIHRvIGNhcmUgYWJvdXQ/IEluIG15 IHZpZXcsIGl0IGlzDQo+IHN1ZmZpY2llbnQgdG8ga25vdyB0aGF0IGEgY2VydGFpbiB2YWx1ZSBp cyB0aGVyZS4NCg0KVGhlIGluZm9ybWF0aW9uIGlzIHRoZXJlIHByaW1hcmlseSBmb3IgdGhlIHNl cnZlciwgc28gdGhhdCB3aGVuIGl0DQpyZWNlaXZlcyBhIGxlYWYgbWFya2VkIGFzIGlzLWRlZmF1 bHQ9InRydWUiIGluIGFuIGVkaXQtY29uZmlnLCBpdCBjYW4NCmlnbm9yZSB0aGUgbGVhZi4NCg0K QnV0IEknbSBub3Qgc28gc3VyZSB0aGF0IHRoaXMgZXh0cmEgbWV0YS1kYXRhIHNvbHZlcyBhbnkg cHJvYmxlbS4gIElmDQp3ZSBzdGljayB0byB0aGUgaWRlYSB0aGF0IGEgc2VydmVyIHRoYXQgaW1w bGVtZW50cyB0aGUgZXhwbGljaXQgbW9kZQ0KZG9lcyBub3QgaGF2ZSB0byBzZW5kIGRlZmF1bHQg dmFsdWVzIGJhY2ssIGl0IG1lYW5zIHRoYXQgaXQgaXMgc2FmZQ0KZm9yIGEgY2xpZW50IHRvIGRv IHNhdmUgLyByZXN0b3JlIG9uIHRoZSBzYW1lIHR5cGUgb2YgZGV2aWNlcywgZXZlbg0Kdy9vIHRo aXMgbWV0YS1kYXRhLg0KDQpBIHJlbGF0ZWQgcHJvYmxlbSB3aXRoIHRoaXMgbWV0YS1kYXRhIGlz IHRoYXQgaXQgZm9yY2VzIHJlcG9ydC1hbGwNCmRldmljZXMgdG8ga2VlcCB0cmFjayBvZiB3aG8g Y3JlYXRlZCB0aGUgbGVhZiwgKGVzc2VudGlhbGx5IG1ha2luZw0KcmVwb3J0LWFsbCBkZXZpY2Vz IGltcGxlbWVudCB0aGUgZXhwbGljaXQgbW9kZSksIHdoaWNoIGdvZXMgYWdhaW5zdA0KdGhlIG9y aWdpbmFsIHVzZSBjYXNlLCBpLmUuIHRoYXQgdGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyB3aGlj aA0KY2Fubm90IGRpc3Rpbmd1aXNoIGJldHdlZW4gbGVhZnMgdGhhdCBoYXZlIGJlZW4gZXhwbGlj aXRseSBzZXQgYW5kDQpsZWFmcyB3aGljaCBoYXZlIHRoZWlyIGRlZmF1bHRzIChpZiB0aGV5IGNv dWxkLCB3ZSBjb3VsZCByZXF1aXJlDQpldmVyeW9uZSB0byBpbXBsZW1lbnQgdGhlIGV4cGxpY2l0 IG1vZGUpLg0KDQoNCg0KL21hcnRpbg0K From andy@netconfcentral.com Fri Sep 25 02:05:51 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 DDEBC3A6855 for ; Fri, 25 Sep 2009 02:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 OzoN9JrpR3ls for ; Fri, 25 Sep 2009 02:05:51 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 049E53A67FC for ; Fri, 25 Sep 2009 02:05:50 -0700 (PDT) Received: (qmail 24450 invoked from network); 25 Sep 2009 09:06:51 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.126.243.218 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 25 Sep 2009 09:06:51 -0000 X-YMail-OSG: aG97BDoVM1kexloSDH8w56i7k_QH.1vdWjOeP_9a72ECiihAVeUMbreOnl1YFWq9kQwNhIeHA6eeQlYGN8F3lxd5FAwUsqdy8kwEN9EUuUAjprH9ky6kZEdw86pkMUKXUH14RmsQC_3DJm80NPuRblJZJgPFEFNLWvdbDEDIz632Kn1yZLr3vk2lWqlrcIzcaW2_j23QVm3lp4tmcwSWfIDAQdU67lCUuuev5yfd.0F.AYJ._8y6O0tvsmPC6PDNKKqn57F_XvgJsfZRRD1_1BC7W27F3sQT4RWBAcp2jIB.98D8NxHgrBdxeZzerXECYjRz X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ABC8852.6080506@netconfcentral.com> Date: Fri, 25 Sep 2009 02:07:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> <1253864312.11615.4.camel@missotis> <20090925.100138.112555560.mbj@tail-f.com> In-Reply-To: <20090925.100138.112555560.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 09:05:52 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Kent Watsen píše v Čt 24. 09. 2009 v 17:01 -0700: >>> Hi All, >>> >>> My primary comment is that, when using "report-all", the client has no >>> way of knowing which values were explicitly set without also getting >>> the "explicit" config, which would be a waste of bandwidth... >> Is this something that the client has to care about? In my view, it is >> sufficient to know that a certain value is there. > > The information is there primarily for the server, so that when it > receives a leaf marked as is-default="true" in an edit-config, it can > ignore the leaf. > > But I'm not so sure that this extra meta-data solves any problem. If > we stick to the idea that a server that implements the explicit mode > does not have to send default values back, it means that it is safe > for a client to do save / restore on the same type of devices, even > w/o this meta-data. > > A related problem with this meta-data is that it forces report-all > devices to keep track of who created the leaf, (essentially making > report-all devices implement the explicit mode), which goes against > the original use case, i.e. that there are implementations which > cannot distinguish between leafs that have been explicitly set and > leafs which have their defaults (if they could, we could require > everyone to implement the explicit mode). > For implementors of explicit mode, they must keep a bit for 'server-set' or they could not save to NV-store properly. Another issue: explicit mode has no relationship whatsoever with the YANG default value, so tagging all server nodes as 'is_default' is misleading. YAI: YANG doesn't support XML attributes, so we can't actually use YANG to model this attribute (modulo the extension hack used for ). YYAI: The client may not want this tagging, so 2 modes for report-all are needed. Perhaps a new enum called 'report-all-tagged'? Before I was thinking that a client would risk having the config change underneath if 2 get-config requests were needed: defaults = get-config(report-all) - get-config(trim) But I forgot that the client can just lock the config first, so the config will not change between the 1st and 2nd get-config. Now this 'is_default' tag seems nice-to-have, but not critical. > > > /martin Andy From lhotka@cesnet.cz Fri Sep 25 02:19:25 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 26FFE3A67AC for ; Fri, 25 Sep 2009 02:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, 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 vCTQ56JzOjGy for ; Fri, 25 Sep 2009 02:19:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5A2DD3A6782 for ; Fri, 25 Sep 2009 02:19:24 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6B46FD800D1; Fri, 25 Sep 2009 11:20:34 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4ABC8852.6080506@netconfcentral.com> References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> <1253864312.11615.4.camel@missotis> <20090925.100138.112555560.mbj@tail-f.com> <4ABC8852.6080506@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 25 Sep 2009 11:20:33 +0200 Message-Id: <1253870433.13541.9.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 09:19:25 -0000 Andy Bierman píše v Pá 25. 09. 2009 v 02:07 -0700: > > YAI: YANG doesn't support XML attributes, so we can't > actually use YANG to model this attribute (modulo the > extension hack used for ). > Actually, this would be a good use of XML attributes and it could be defined in the specification of the mapping from the conceptual data tree to the "explicit" view of the datastore, not in core YANG. > YYAI: The client may not want this tagging, so 2 > modes for report-all are needed. > Perhaps a new enum called 'report-all-tagged'? If the client asks for "explicit", it should be prepared for handling these tags, and they should not appear in the "report-all" and "trim" views. If the server doesn't support with-defaults and uses "explicit", this information may get lost. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Sep 25 03:18: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 C1F1E3A6948 for ; Fri, 25 Sep 2009 03:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.131, 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 sdf-LRQkCq7W for ; Fri, 25 Sep 2009 03:18:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 932733A68A5 for ; Fri, 25 Sep 2009 03:18:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8B81C0029; Fri, 25 Sep 2009 12:19:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Lu06RgljDY8I; Fri, 25 Sep 2009 12:19:52 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8107BC0003; Fri, 25 Sep 2009 12:19:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6CACACFEF0D; Fri, 25 Sep 2009 12:19:51 +0200 (CEST) Date: Fri, 25 Sep 2009 12:19:51 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090925101951.GA18442@elstar.local> Mail-Followup-To: Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> <1253864312.11615.4.camel@missotis> <20090925.100138.112555560.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090925.100138.112555560.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 10:18:44 -0000 On Fri, Sep 25, 2009 at 10:01:38AM +0200, Martin Bjorklund wrote: > But I'm not so sure that this extra meta-data solves any problem. If > we stick to the idea that a server that implements the explicit mode > does not have to send default values back, it means that it is safe > for a client to do save / restore on the same type of devices, even > w/o this meta-data. The proposal essentially avoids having clients computing diffs between report-all and explit configs. This is nice but it opens up the floor for attributes and meta data in XML content, perhaps something we like to avoid / postpone at this point in time. > A related problem with this meta-data is that it forces report-all > devices to keep track of who created the leaf, (essentially making > report-all devices implement the explicit mode), which goes against > the original use case, i.e. that there are implementations which > cannot distinguish between leafs that have been explicitly set and > leafs which have their defaults (if they could, we could require > everyone to implement the explicit mode). Everyone supporting explicit would be a win if you ask me. Perhaps we should have a poll to see how many actually would not be able to support explicit. And we should kill trim - I do not see why someone would want that operationally. /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 Fri Sep 25 04:37: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 5B7E23A6948 for ; Fri, 25 Sep 2009 04:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 pQjx4PRP7yQY for ; Fri, 25 Sep 2009 04:37:47 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8EBFF3A6970 for ; Fri, 25 Sep 2009 04:37:47 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4AD6876C4F6; Fri, 25 Sep 2009 13:38:57 +0200 (CEST) Date: Fri, 25 Sep 2009 13:38:56 +0200 (CEST) Message-Id: <20090925.133856.207928614.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1253870433.13541.9.camel@missotis> References: <20090925.100138.112555560.mbj@tail-f.com> <4ABC8852.6080506@netconfcentral.com> <1253870433.13541.9.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 11:37:48 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFu IHDDrcWhZSB2IFDDoSAyNS4gMDkuIDIwMDkgdiAwMjowNyAtMDcwMDoNCj4gPiBZWUFJOiBUaGUg Y2xpZW50IG1heSBub3Qgd2FudCB0aGlzIHRhZ2dpbmcsIHNvIDINCj4gPiBtb2RlcyBmb3IgcmVw b3J0LWFsbCBhcmUgbmVlZGVkLg0KPiA+IFBlcmhhcHMgYSBuZXcgZW51bSBjYWxsZWQgJ3JlcG9y dC1hbGwtdGFnZ2VkJz8NCj4gDQo+IElmIHRoZSBjbGllbnQgYXNrcyBmb3IgImV4cGxpY2l0Iiwg aXQgc2hvdWxkIGJlIHByZXBhcmVkIGZvciBoYW5kbGluZw0KPiB0aGVzZSB0YWdzLCBhbmQgdGhl eSBzaG91bGQgbm90IGFwcGVhciBpbiB0aGUgInJlcG9ydC1hbGwiIGFuZCAidHJpbSINCj4gdmll d3MuDQoNCkl0IG11c3QgYmUgdGhlIG90aGVyIHdheSBhcm91bmQuICBUaGUgb3JpZ2luYWwgaWRl YSB3YXMgdG8gdXNlIHRoaXMNCmF0dHJpYnV0ZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIGRlZmF1 bHRzIGluIGVmZmVjdCBmcm9tIGV4cGxpY2l0bHkNCmNyZWF0ZWQgdmFsdWVzLiAgU28gaWYgcmVw b3J0LWFsbCBzdGlsbCBqdXN0IHNlbmRzIGV2ZXJ5dGhpbmcgdy9vIHRoaXMNCmF0dHJpYnV0ZSwg d2UgaGF2ZW7DpHQgc29sdmVkIGFueXRoaW5nLiAgQW5kIGV4cGxpY2l0IGlzIGRlZmluZWQgdG8g Tk9UDQpzZW5kIGRlZmF1bHRzLg0KDQoNCi9tYXJ0aW4NCg== From phil@juniper.net Fri Sep 25 05:41: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 277FC3A693D for ; Fri, 25 Sep 2009 05:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 EWeSV7zeXZol for ; Fri, 25 Sep 2009 05:41:10 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 045C73A6931 for ; Fri, 25 Sep 2009 05:41:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSry6qPqnj+DNnRKyi1NyP08mlwPVtIw3@postini.com; Fri, 25 Sep 2009 05:42:21 PDT 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.375.2; Fri, 25 Sep 2009 05:37:49 -0700 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, 25 Sep 2009 05:37:49 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 05:37:48 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 05:37:48 -0700 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 n8PCblj64754; Fri, 25 Sep 2009 05:37:47 -0700 (PDT) (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 n8PCPIf2095196; Fri, 25 Sep 2009 12:25:19 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909251225.n8PCPIf2095196@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090925101951.GA18442@elstar.local> Date: Fri, 25 Sep 2009 08:25:18 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Sep 2009 12:37:48.0348 (UTC) FILETIME=[FD31CFC0:01CA3DDC] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 12:41:11 -0000 Juergen Schoenwaelder writes: >Everyone supporting explicit would be a win if you ask me. Perhaps we >should have a poll to see how many actually would not be able to >support explicit. And we should kill trim - I do not see why someone >would want that operationally. I'm all for "explicit" and consider it the best solution, but "trim" is the mechanism used by IOS and IOS-like devices, where setting a leaf to the default value causes the leaf to disappear (when the central OS asks a component to report its config settings, the component reports any non-default values, but does not retain a bit to say whether the default was explicitly set or not). I would assume that removing the ability to take the "trim" approach would significantly increase the implementation cost (and reduce the compliance) of such vendors, so keeping it makes sense in maximizing the market adoption of YANG. Thanks, Phil From andy@netconfcentral.com Fri Sep 25 07:19: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 2EEC63A689F for ; Fri, 25 Sep 2009 07:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 xLZuSDLtKEbD for ; Fri, 25 Sep 2009 07:19:34 -0700 (PDT) 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 34E193A63EB for ; Fri, 25 Sep 2009 07:19:34 -0700 (PDT) Received: (qmail 85228 invoked from network); 25 Sep 2009 14:20:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.126.243.218 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 25 Sep 2009 14:20:43 -0000 X-YMail-OSG: YXDUWSsVM1m9vbGoJfeoY8CRObpZyrdhSgwJT69iZUwTyjCEprqcjg7WXcdV3AYrWlBCUxGlljeMrt4uSsW.jjRLGZpgL_GYXoFGtacCxM6jomGGbJCEY54Nd3f9ugK56fRwlnJpmOfSOi8cpl.fA6WbEM2vAQ4N8iG5ZUzgeUm8toGWbeVikxpDIAIIrOUFlGt5X80oGLtAhgiDjU2GXAEerw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ABCD169.9020008@netconfcentral.com> Date: Fri, 25 Sep 2009 07:19:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> <1253864312.11615.4.camel@missotis> <20090925.100138.112555560.mbj@tail-f.com> <20090925101951.GA18442@elstar.local> In-Reply-To: <20090925101951.GA18442@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 14:19:35 -0000 Juergen Schoenwaelder wrote: > On Fri, Sep 25, 2009 at 10:01:38AM +0200, Martin Bjorklund wrote: > >> But I'm not so sure that this extra meta-data solves any problem. If >> we stick to the idea that a server that implements the explicit mode >> does not have to send default values back, it means that it is safe >> for a client to do save / restore on the same type of devices, even >> w/o this meta-data. > > The proposal essentially avoids having clients computing diffs between > report-all and explit configs. This is nice but it opens up the floor > for attributes and meta data in XML content, perhaps something we like > to avoid / postpone at this point in time. > >> A related problem with this meta-data is that it forces report-all >> devices to keep track of who created the leaf, (essentially making >> report-all devices implement the explicit mode), which goes against >> the original use case, i.e. that there are implementations which >> cannot distinguish between leafs that have been explicitly set and >> leafs which have their defaults (if they could, we could require >> everyone to implement the explicit mode). > > Everyone supporting explicit would be a win if you ask me. Perhaps we > should have a poll to see how many actually would not be able to > support explicit. And we should kill trim - I do not see why someone > would want that operationally. > The NV-storage is linked to with-defaults. The WG decided the operator should have no control over this at all (remember with-defaults for copy-config to startup?). Now the 'basic' with-defaults behavior controls how NV-store works. This is left up to the server implementation and should stay that way. Defaults across reboots sometimes change if the device SW image changes, or the device itself changes (hotswap, plug-in module, etc.) Blindly trusting defaults works great until it stops working great, and then you have to fix it. This is just another capability the client needs to deal with amongst dozens of them. FWIW, in my code this is all configurable, plus there is a special RPC (set-my-session) that lets each session set their own default for with-defaults, instead of using the parameter leaf. I think the 'basic' behavior should remain configurable by the operator, not hard-wired to 'explicit'. > /js > Andy From Washam.Fan@huaweisymantec.com Fri Sep 25 07:49:15 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 7FC3B3A69DA for ; Fri, 25 Sep 2009 07:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.667 X-Spam-Level: X-Spam-Status: No, score=-0.667 tagged_above=-999 required=5 tests=[AWL=-0.172, 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 17a8hCC0kIKu for ; Fri, 25 Sep 2009 07:49:14 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 7801D3A69D7 for ; Fri, 25 Sep 2009 07:49:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-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 <0KQJ003TS7V6S430@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 25 Sep 2009 22:49:55 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KQJ00LQV7V6TZ20@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 25 Sep 2009 22:49:54 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Fri, 25 Sep 2009 22:49:54 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Fri, 25 Sep 2009 22:49:54 +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: <4ABC8852.6080506@netconfcentral.com> References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> <1253864312.11615.4.camel@missotis> <20090925.100138.112555560.mbj@tail-f.com> <4ABC8852.6080506@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 14:49:15 -0000 > Before I was thinking that a client would risk > having the config change underneath if 2 get-config > requests were needed: > > defaults = get-config(report-all) - get-config(trim) I'd like to add: explicitly set defaults = get-config(report-all) - get-config(explicit) operationally used defaults = get-config(explicit) - get-config(trim) washam > But I forgot that the client can just lock the config first, > so the config will not change between the 1st and 2nd get-config. > Now this 'is_default' tag seems nice-to-have, but not critical. > > > > > > > > /martin > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Fri Sep 25 08:05:58 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 0855A3A69DB for ; Fri, 25 Sep 2009 08:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_05=-1.11, 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 b+2qTKS8ZX1i for ; Fri, 25 Sep 2009 08:05:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 14E593A69A4 for ; Fri, 25 Sep 2009 08:05:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC5E1C001C; Fri, 25 Sep 2009 17:07:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1A-IIQDingsj; Fri, 25 Sep 2009 17:07:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D2DCC0006; Fri, 25 Sep 2009 17:07:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 24482CFF4AD; Fri, 25 Sep 2009 17:07:06 +0200 (CEST) Date: Fri, 25 Sep 2009 17:07:06 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090925150706.GA18860@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> <1253864312.11615.4.camel@missotis> <20090925.100138.112555560.mbj@tail-f.com> <20090925101951.GA18442@elstar.local> <4ABCD169.9020008@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ABCD169.9020008@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 15:05:58 -0000 On Fri, Sep 25, 2009 at 04:19:21PM +0200, Andy Bierman wrote: > I think the 'basic' behavior should remain configurable > by the operator, not hard-wired to 'explicit'. Still if would be cool if every netconf server would allow me to use explicit mode if I choose so... But I might be dreaming. /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 Fri Sep 25 08:26:59 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 102AD3A6A51 for ; Fri, 25 Sep 2009 08:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 h6VrzCG0kLxp for ; Fri, 25 Sep 2009 08:26:58 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 314CC3A6A50 for ; Fri, 25 Sep 2009 08:26:58 -0700 (PDT) Received: (qmail 77346 invoked from network); 25 Sep 2009 15:28:06 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.126.243.218 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 25 Sep 2009 15:28:06 -0000 X-YMail-OSG: gV0RPSMVM1ldlWquDkMsAWNwsmRFxdhTqBPepAlBnBI.Z_vn4JywoQStR0EjkZ.9Nw8BlAal8R.aLN.9ZpbIYhGrIPRVUjCj4KQ65EZktOBz._3byskHGnm5Ml6wn72uRsmUW1TOiX9lyUgs_7lymGEVsQQW9hZ0sla8Bv8tX37eUPSLjyyxG9AksgReyXyp642NZF9_AelxjTHstYt2TMdZbw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ABCE1AF.9050106@netconfcentral.com> Date: Fri, 25 Sep 2009 08:28:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> <1253864312.11615.4.camel@missotis> <20090925.100138.112555560.mbj@tail-f.com> <20090925101951.GA18442@elstar.local> <4ABCD169.9020008@netconfcentral.com> <20090925150706.GA18860@elstar.local> In-Reply-To: <20090925150706.GA18860@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 15:26:59 -0000 Juergen Schoenwaelder wrote: > On Fri, Sep 25, 2009 at 04:19:21PM +0200, Andy Bierman wrote: > >> I think the 'basic' behavior should remain configurable >> by the operator, not hard-wired to 'explicit'. > > Still if would be cool if every netconf server would allow me to use > explicit mode if I choose so... But I might be dreaming. > Yes -- I realize now why it is the best for normal use. Even if a YANG default changes across reboots, the explicit config doesn't change. For that reason alone, it is way better than 'trim'. IMO, 'report-all' is really for diagnostic mode, not normal mode, but maybe not. It is wrong to assume that NV-storage of 1 XML file is somehow a burden for every platform running NETCONF. > /js > Andy From phil@juniper.net Fri Sep 25 09:14: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 588683A6850 for ; Fri, 25 Sep 2009 09:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 JsGshaRNagp4 for ; Fri, 25 Sep 2009 09:14:20 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 6D8FB3A65A6 for ; Fri, 25 Sep 2009 09:14:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSrzsn0Al6Oi2HNidRHZiJmxYjvleb02G@postini.com; Fri, 25 Sep 2009 09:15:32 PDT 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.375.2; Fri, 25 Sep 2009 09:10:20 -0700 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, 25 Sep 2009 09:10:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 09:10:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 09:10:20 -0700 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 n8PGACj54187; Fri, 25 Sep 2009 09:10:18 -0700 (PDT) (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 n8PFvhQB009338; Fri, 25 Sep 2009 15:57:43 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909251557.n8PFvhQB009338@idle.juniper.net> To: Andy Bierman In-Reply-To: <4ABCE1AF.9050106@netconfcentral.com> Date: Fri, 25 Sep 2009 11:57:43 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Sep 2009 16:10:20.0017 (UTC) FILETIME=[ADC81610:01CA3DFA] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 16:14:21 -0000 Andy Bierman writes: >It is wrong to assume >that NV-storage of 1 XML file is somehow a burden for >every platform running NETCONF. Well, it's wrong to assume that a platform running NETCONF uses XML for anything more than parsing content off the wire. The JUNOS config database is not XML, nor are our NV-storage contents. Also the storage needs for "explicit" or "trim" are not similar to "report-all". For example, the JUNOS list element for static routes has nearly 75 leafs under it, of which 2-3 are typically set. Assuming they all have default (which they don't, but...), the customer that loads 50,000 static routes has a impact (with 32 bytes overhead per list instance plus, say, 12 bytes per leaf instance) of 2.8M for explicit and 46.6M for report-all. Thanks, Phil From jmh@joelhalpern.com Fri Sep 25 09:21: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 A63DF3A69EC for ; Fri, 25 Sep 2009 09:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.334 X-Spam-Level: X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, 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 BM6bB2y-Exr6 for ; Fri, 25 Sep 2009 09:21:45 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DCB8E3A6A24 for ; Fri, 25 Sep 2009 09:21:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 79771430476; Fri, 25 Sep 2009 09:22:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id BB718430466; Fri, 25 Sep 2009 09:22:56 -0700 (PDT) Message-ID: <4ABCEE5E.6020902@joelhalpern.com> Date: Fri, 25 Sep 2009 12:22:54 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200909251557.n8PFvhQB009338@idle.juniper.net> In-Reply-To: <200909251557.n8PFvhQB009338@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 16:21:46 -0000 I think I agree with what I think you mean :-) In your example, if a client took a report-all output and fed it back, and assuming that the system internally uses an explicit model which I think you have said, then the config storage for this case goes from 2.8M to 46.6M. Is that the point? Otherwise, I am very confused. Or are you talking about the size of the output if a client requests explicit vs report-all? That difference is the client's problem they asked for it, give it to them. And, unless someone does the feedback above, your box can presumably happily produce a report-all output even if it stores only explicit. Yours, Joel Phil Shafer wrote: > Andy Bierman writes: >> It is wrong to assume >> that NV-storage of 1 XML file is somehow a burden for >> every platform running NETCONF. > > Well, it's wrong to assume that a platform running NETCONF uses XML > for anything more than parsing content off the wire. The JUNOS > config database is not XML, nor are our NV-storage contents. > > Also the storage needs for "explicit" or "trim" are not similar to > "report-all". For example, the JUNOS list element for static routes > has nearly 75 leafs under it, of which 2-3 are typically set. > Assuming they all have default (which they don't, but...), the > customer that loads 50,000 static routes has a impact (with 32 bytes > overhead per list instance plus, say, 12 bytes per leaf instance) > of 2.8M for explicit and 46.6M for report-all. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@netconfcentral.com Fri Sep 25 09:26: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 C186B3A69E2 for ; Fri, 25 Sep 2009 09:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 dgDNW8AwNx67 for ; Fri, 25 Sep 2009 09:26:32 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id EA6243A63D3 for ; Fri, 25 Sep 2009 09:26:31 -0700 (PDT) Received: (qmail 97104 invoked from network); 25 Sep 2009 16:27:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.126.243.218 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 25 Sep 2009 16:27:40 -0000 X-YMail-OSG: ZyZRhyQVM1lhsAtEdmox5smAqqCmpFlH12tuWRAPgFsdYJMW5qed75M5e3K2nNu67ZEwzLST8PNzeKVq8XqGisQD9rdkjCHWcgktGJm21U4QehlgGxwVOUds0Ly9fvBt2uTj48u08aEUZQnNzetvJkraTbLDEshFnuZ51lh3NDjGKICeliuhFE3WakV5rXQm0nK78LQiUNtVMemnaXfLbhUf.s.I2le4KhT5ovMPTtkbUITCmX4qj3FCSzal98UwPyDUAXt81jkLKK3R X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ABCEFA4.8090300@netconfcentral.com> Date: Fri, 25 Sep 2009 09:28:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200909251557.n8PFvhQB009338@idle.juniper.net> In-Reply-To: <200909251557.n8PFvhQB009338@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 16:26:32 -0000 Phil Shafer wrote: > Andy Bierman writes: >> It is wrong to assume >> that NV-storage of 1 XML file is somehow a burden for >> every platform running NETCONF. > > Well, it's wrong to assume that a platform running NETCONF uses XML > for anything more than parsing content off the wire. The JUNOS > config database is not XML, nor are our NV-storage contents. > This is fine as long as you don't use a distinct startup config (and you don't I think). If the startup is saved via copy-config from running to startup, then (IMO) it must be in the same format as a would return. > Also the storage needs for "explicit" or "trim" are not similar to > "report-all". For example, the JUNOS list element for static routes > has nearly 75 leafs under it, of which 2-3 are typically set. > Assuming they all have default (which they don't, but...), the > customer that loads 50,000 static routes has a impact (with 32 bytes > overhead per list instance plus, say, 12 bytes per leaf instance) > of 2.8M for explicit and 46.6M for report-all. > I agree that 'explicit' is the best for NV-storage. The operator picks what is saved, not the server, and that is key. But XML compresses well if you care about Flash write times and limited capacity. XML filesize is a non-factor if there is a hard drive instead of Flash memory. At 10 cents a megabyte (retail) and falling, this will become less and less of an issue over time. Moore's law is working faster than the configs are growing. > Thanks, > Phil > Andy From phil@juniper.net Fri Sep 25 11:16:52 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 4475B3A6A70 for ; Fri, 25 Sep 2009 11:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 8RLlLrIXbiGQ for ; Fri, 25 Sep 2009 11:16:51 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 6048E3A6A06 for ; Fri, 25 Sep 2009 11:16:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSr0JVKgJ2w8osk3LHN5ys43DbIO1VCj6@postini.com; Fri, 25 Sep 2009 11:18:03 PDT 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.375.2; Fri, 25 Sep 2009 11:08:17 -0700 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, 25 Sep 2009 11:08:17 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 11:08:17 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 11:08:16 -0700 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 n8PI8Cj08204; Fri, 25 Sep 2009 11:08:14 -0700 (PDT) (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 n8PHthdT016982; Fri, 25 Sep 2009 17:55:44 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909251755.n8PHthdT016982@idle.juniper.net> To: Andy Bierman In-Reply-To: <4ABCEFA4.8090300@netconfcentral.com> Date: Fri, 25 Sep 2009 13:55:43 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Sep 2009 18:08:16.0036 (UTC) FILETIME=[276AE640:01CA3E0B] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 18:16:52 -0000 Andy Bierman writes: >This is fine as long as you don't use a >distinct startup config (and you don't I think). Even distinct-startup does not require that the format on the disk be XML. >At 10 cents a megabyte (retail) and falling, this will >become less and less of an issue over time. Moore's law >is working faster than the configs are growing. Sure, but in the end, some bean counter decides how much flash a device gets and the rest of us have to live with it. (Not that I'm bitter ;^) Thanks, Phil From phil@juniper.net Fri Sep 25 11:20: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 752783A6980 for ; Fri, 25 Sep 2009 11:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 9oZDP3avIbbO for ; Fri, 25 Sep 2009 11:20:42 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 364593A6939 for ; Fri, 25 Sep 2009 11:20:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSr0KP+lUXXUajS+aARjnpj17FK4c9aGk@postini.com; Fri, 25 Sep 2009 11:21:54 PDT 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.375.2; Fri, 25 Sep 2009 11:11:42 -0700 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, 25 Sep 2009 11:11:43 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 11:11:42 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 11:11:41 -0700 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 n8PIBej10435; Fri, 25 Sep 2009 11:11:41 -0700 (PDT) (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 n8PHxCxl017232; Fri, 25 Sep 2009 17:59:12 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909251759.n8PHxCxl017232@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4ABCEE5E.6020902@joelhalpern.com> Date: Fri, 25 Sep 2009 13:59:11 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Sep 2009 18:11:41.0598 (UTC) FILETIME=[A1F12BE0:01CA3E0B] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 18:20:43 -0000 "Joel M. Halpern" writes: >I think I agree with what I think you mean :-) Sorry if I overtrimmed Andy's comment. He said maybe it didn't matter if the device had to save the config in report-all, full of defaults style, and my point was that it can eat an order of magnitude more flash/disk space, which isn't an unlimited resource. Thanks, Phil From jmh@joelhalpern.com Fri Sep 25 11:28: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 140723A6A7A for ; Fri, 25 Sep 2009 11:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, 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 k6VZtPsfOkXA for ; Fri, 25 Sep 2009 11:28:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6F6C93A6817 for ; Fri, 25 Sep 2009 11:28:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3E9E8430568; Fri, 25 Sep 2009 11:29:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 91659430560; Fri, 25 Sep 2009 11:29:12 -0700 (PDT) Message-ID: <4ABD0BF6.8050404@joelhalpern.com> Date: Fri, 25 Sep 2009 14:29:10 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200909251759.n8PHxCxl017232@idle.juniper.net> In-Reply-To: <200909251759.n8PHxCxl017232@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 18:28:02 -0000 Thanks. That's what I thought you meant. Joel Phil Shafer wrote: > "Joel M. Halpern" writes: >> I think I agree with what I think you mean :-) > > Sorry if I overtrimmed Andy's comment. He said maybe it didn't > matter if the device had to save the config in report-all, full of > defaults style, and my point was that it can eat an order of magnitude > more flash/disk space, which isn't an unlimited resource. > > Thanks, > Phil > From andy@netconfcentral.com Fri Sep 25 12:14:29 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 76F8E3A67E7 for ; Fri, 25 Sep 2009 12:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.350, 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 QPfByD7oUhSN for ; Fri, 25 Sep 2009 12:14:28 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id 970E53A68D3 for ; Fri, 25 Sep 2009 12:14:28 -0700 (PDT) Received: from [209.191.108.97] by n20.bullet.mail.mud.yahoo.com with NNFMP; 25 Sep 2009 19:15:38 -0000 Received: from [68.142.201.248] by t4.bullet.mud.yahoo.com with NNFMP; 25 Sep 2009 19:15:38 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 25 Sep 2009 19:15:38 -0000 X-Yahoo-Newman-Id: 523540.45539.bm@omp409.mail.mud.yahoo.com Received: (qmail 35394 invoked from network); 25 Sep 2009 19:15:38 -0000 Received: from ppp-67-126-243-218.dsl.irvnca.pacbell.net (andy@67.126.243.218 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 25 Sep 2009 12:15:37 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: puD3jfEVM1lvTgaWiaaDw3mUBTLN5_D4MzG6d5v6Wt9H9pZVEG2rGtp.9DKwGwd3NMI3fwrvEvMhZM05Jx.A9RWGUutGspDgjPN53c2SsMWo43V5VMVLgwxG4H3b5WYr0lT9aNbTGzTvSxVbgO2tPK14PTVMWunk001yAViCAulfXM2T45LyxPXgMJQzQaSPlEYdX4Q3dzGIIxA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ABD1703.4020703@netconfcentral.com> Date: Fri, 25 Sep 2009 12:16:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200909251755.n8PHthdT016982@idle.juniper.net> In-Reply-To: <200909251755.n8PHthdT016982@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 19:14:29 -0000 Phil Shafer wrote: > Andy Bierman writes: >> This is fine as long as you don't use a >> distinct startup config (and you don't I think). > > Even distinct-startup does not require that the format on the disk > be XML. Some of us think that is a bug, not a feature. Do we need a separate RFC to say that a standard NETCONF config file is an XML instance document containing the element? I was hoping we could put that in 4741bis. > >> At 10 cents a megabyte (retail) and falling, this will >> become less and less of an issue over time. Moore's law >> is working faster than the configs are growing. > > Sure, but in the end, some bean counter decides how much flash a > device gets and the rest of us have to live with it. (Not that I'm > bitter ;^) yep. And they always want to give 'flash upgrade options' super high markups, so you really are stuck with too little NV-store most of the time. > > Thanks, > Phil > Andy From kwatsen@juniper.net Fri Sep 25 12:15: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 404E83A6973 for ; Fri, 25 Sep 2009 12:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 bZOtm7euI4iL for ; Fri, 25 Sep 2009 12:15:19 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 5B94C3A693F for ; Fri, 25 Sep 2009 12:15:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSr0XDHvVJ9dwA2r8yrrO7+AGq4Q4oW0E@postini.com; Fri, 25 Sep 2009 12:16:31 PDT 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; Fri, 25 Sep 2009 12:10:38 -0700 From: Kent Watsen To: 'Martin Bjorklund' , "lhotka@cesnet.cz" Date: Fri, 25 Sep 2009 12:10:38 -0700 Thread-Topic: [Netconf] review of draft-ietf-netconf-with-defaults-03 Thread-Index: Aco9tmpg6evTTzdFSHOgptozRFGy2gAXOXLQ Message-ID: <84600D05C20FF943918238042D7670FD36646BFAF5@EMBX01-HQ.jnpr.net> References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> <1253864312.11615.4.camel@missotis> <20090925.100138.112555560.mbj@tail-f.com> In-Reply-To: <20090925.100138.112555560.mbj@tail-f.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] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 19:15:20 -0000 Martin Bjorklund wrote: > But I'm not so sure that this extra meta-data solves any problem. If > we stick to the idea that a server that implements the explicit mode > does not have to send default values back, it means that it is safe > for a client to do save / restore on the same type of devices, even > w/o this meta-data. Already a server supporting "explicit" is not required to support "report-a= ll", but what if it does? - then aren't the defaults required to be return= ed? Thanks, Kent From kwatsen@juniper.net Fri Sep 25 12:15:51 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 F3F943A6A11 for ; Fri, 25 Sep 2009 12:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 xhhJ5qyL2R1A for ; Fri, 25 Sep 2009 12:15:50 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 16E5B3A690C for ; Fri, 25 Sep 2009 12:15:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSr0XKoZlelcNzhMWlZXYXb1fmisnlKj3@postini.com; Fri, 25 Sep 2009 12:17:02 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Fri, 25 Sep 2009 12:13:54 -0700 From: Kent Watsen To: 'Andy Bierman' , Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" Date: Fri, 25 Sep 2009 12:13:53 -0700 Thread-Topic: [Netconf] review of draft-ietf-netconf-with-defaults-03 Thread-Index: Aco99MvixArWV5A6RaiU7asTpgjUPQAFDsFQ Message-ID: <84600D05C20FF943918238042D7670FD36646BFAF6@EMBX01-HQ.jnpr.net> References: <1250760650.23073.3.camel@missotis> <84600D05C20FF943918238042D7670FD36646BFAEB@EMBX01-HQ.jnpr.net> <1253864312.11615.4.camel@missotis> <20090925.100138.112555560.mbj@tail-f.com> <20090925101951.GA18442@elstar.local> <4ABCD169.9020008@netconfcentral.com> <20090925150706.GA18860@elstar.local> <4ABCE1AF.9050106@netconfcentral.com> In-Reply-To: <4ABCE1AF.9050106@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 Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 19:15:51 -0000 > Andy Bierman wrote: > IMO, 'report-all' is really for diagnostic mode, not normal mode, but may= be not. =20 Yes, for management applications, where development effort will likely be e= xtended to be meta-data aware. But what about simple scripts? A script ne= eding to act on the conceptual tree (i.e. includes defaults) would use "rep= ort-all" and, when submitting the change back to the device, could unknowin= gly create a bunch of explicit nodes... Maybe the questions is - how likely is it that a server supporting "explici= t" would also support "report-all" and a client would use the output of rep= ort-all as input to ? Also, we could ask about the worst case= scenario (2.8M --> 46.6M) - hope the device includes a rollback feature ;) Thanks, Kent From randy_presuhn@mindspring.com Fri Sep 25 12:23: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 328B43A6A66 for ; Fri, 25 Sep 2009 12:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_50=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 TGDBqywnfrt8 for ; Fri, 25 Sep 2009 12:23:17 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 6EBF03A694E for ; Fri, 25 Sep 2009 12:23:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bZtet5lXpAEQbbZz3YfTQ3BdBph1JsdxWmSF6zerZHNj0Vn6PqHTV0mm7EnXSZry; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.48.107] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MrGP6-0006yq-Ft for netconf@ietf.org; Fri, 25 Sep 2009 15:24:28 -0400 Message-ID: <001b01ca3e15$e64690a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200909251755.n8PHthdT016982@idle.juniper.net> <4ABD1703.4020703@netconfcentral.com> Date: Fri, 25 Sep 2009 12:25:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9159455f111165281f38434dd88859d50350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.48.107 Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 19:23:18 -0000 Hi - > From: "Andy Bierman" > To: "Phil Shafer" > Cc: > Sent: Friday, September 25, 2009 12:16 PM > Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 ... > Do we need a separate RFC to say that a standard > NETCONF config file is an XML instance document containing > the element? I was hoping we could put > that in 4741bis. ... Conformance to the protocol should not dictate the format a system uses internally. If folks think it is desirable to have a specification of a "standard NETCONF config file format", fine, but conformance to that specification should be kept completely independent of claims of conformance to the protocol, in the same way that conformance to AgentX is a completely separate question from whether a system conforms to the SNMPv3 specifications. Randy From andy@netconfcentral.com Fri Sep 25 12:53: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 50FF228C0DB for ; Fri, 25 Sep 2009 12:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 G09fJzFHfqlQ for ; Fri, 25 Sep 2009 12:53:37 -0700 (PDT) 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 79F933A68AA for ; Fri, 25 Sep 2009 12:53:37 -0700 (PDT) Received: (qmail 49750 invoked from network); 25 Sep 2009 19:54:47 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.126.243.218 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 25 Sep 2009 19:54:47 -0000 X-YMail-OSG: hYsqFRgVM1mMbYNwh5EAP9ysgA4DXeGE2pcw6Po_ubTTABswfpNvQywME7iIDO4X0yRM96pKHtcY_sO3Wt9XuD_QVbtw47PotdTTheLwRnEeLhOL.vYsDFjv5d4pjkoXxty2JCcK6RbkjBD9ur6PNavUKBUbyoT7r.G_lZd.F_M4y2.8L7qqzAegAyDb.KUWW5tJ0QpntpVB.OpkwBn1BAS.MgqIOGdfvfBpCaDngeFHF8FKNdj7mZtnUgZp7d2P1KQQthuqHQsftNdUBWuRI5qN.nAI5MAN_eUQHa0AZc0_3YMS X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ABD2030.6000307@netconfcentral.com> Date: Fri, 25 Sep 2009 12:55:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Randy Presuhn References: <200909251755.n8PHthdT016982@idle.juniper.net> <4ABD1703.4020703@netconfcentral.com> <001b01ca3e15$e64690a0$6801a8c0@oemcomputer> In-Reply-To: <001b01ca3e15$e64690a0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 19:53:38 -0000 Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Phil Shafer" >> Cc: >> Sent: Friday, September 25, 2009 12:16 PM >> Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 > ... >> Do we need a separate RFC to say that a standard >> NETCONF config file is an XML instance document containing >> the element? I was hoping we could put >> that in 4741bis. > ... > > Conformance to the protocol should not dictate the format a system > uses internally. If folks think it is desirable to have a specification of > a "standard NETCONF config file format", fine, but conformance > to that specification should be kept completely independent of > claims of conformance to the protocol, in the same way that > conformance to AgentX is a completely separate question from > whether a system conforms to the SNMPv3 specifications. > OK -- so you are saying we need a separate RFC for the standard file format for the XML representation of a NETCONF database. This is useful to have if NETCONF reaches any level of interoperability at all. If 2 compliant servers both support the same set of YANG modules/revisions represented in the XML document, then a startup-cfg.xml for one device should work on the other. (Sorry if this level of interoperability is too bizarre to comprehend in the embedded NM world. ;-) > Randy > Andy From mbj@tail-f.com Fri Sep 25 13:20: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 7B7023A68E8 for ; Fri, 25 Sep 2009 13:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 U0K+WDboxPhH for ; Fri, 25 Sep 2009 13:20:26 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A35243A68CE for ; Fri, 25 Sep 2009 13:20:26 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6301776C4F6; Fri, 25 Sep 2009 22:21:37 +0200 (CEST) Date: Fri, 25 Sep 2009 22:21:37 +0200 (CEST) Message-Id: <20090925.222137.52411666.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <001b01ca3e15$e64690a0$6801a8c0@oemcomputer> References: <200909251755.n8PHthdT016982@idle.juniper.net> <4ABD1703.4020703@netconfcentral.com> <001b01ca3e15$e64690a0$6801a8c0@oemcomputer> X-Mailer: Mew version 6.0.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] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 20:20:27 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Andy Bierman" > > To: "Phil Shafer" > > Cc: > > Sent: Friday, September 25, 2009 12:16 PM > > Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 > ... > > Do we need a separate RFC to say that a standard > > NETCONF config file is an XML instance document containing > > the element? I was hoping we could put > > that in 4741bis. > ... > > Conformance to the protocol should not dictate the format a system > uses internally. +1. In this particular case, as long as on startup produces the correct XML, it doesn't matter what form the data is stored internally. However, the format of what goes into a URL file used by isn't specified, but should be (see http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis#issue-012). This still just means that the format produced / consumed by the is well-defined; it doesn't mean that the file format MUST be the same. /martin From andy@netconfcentral.com Fri Sep 25 13:46: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 9B2F63A6845 for ; Fri, 25 Sep 2009 13:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 tNQRZFH9ku8j for ; Fri, 25 Sep 2009 13:46:34 -0700 (PDT) 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 B7F823A67F4 for ; Fri, 25 Sep 2009 13:46:34 -0700 (PDT) Received: (qmail 15588 invoked from network); 25 Sep 2009 20:47:44 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.126.243.218 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 25 Sep 2009 20:47:44 -0000 X-YMail-OSG: jaczX6YVM1lREGuf972Qnski4r9AyKH16KQbeMEmt3LjAlBQUUowMeA_.MieTDkZzyr.FPFOMSJBQwK8XxftgUgeCo9O1PnbiDv6W3YdqAGXbitctT.bF34NQ7MwvAR8khzt5RUnUyW1mf78Qf1clxTtRz83oHQWVhBQgJYGi3WHnGDOt6Ute2Bha0hiuwQ9VIjaJ_UefxWgbAEqK0hRpOUUmwFKdwZyugo42bax3TBvyVMTTvHcuOj.bQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ABD2C1D.8040506@netconfcentral.com> Date: Fri, 25 Sep 2009 13:46:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200909251755.n8PHthdT016982@idle.juniper.net> <4ABD1703.4020703@netconfcentral.com> <001b01ca3e15$e64690a0$6801a8c0@oemcomputer> <20090925.222137.52411666.mbj@tail-f.com> In-Reply-To: <20090925.222137.52411666.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 20:46:35 -0000 Martin Bjorklund wrote: > "Randy Presuhn" wrote: >> Hi - >> >>> From: "Andy Bierman" >>> To: "Phil Shafer" >>> Cc: >>> Sent: Friday, September 25, 2009 12:16 PM >>> Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 >> ... >>> Do we need a separate RFC to say that a standard >>> NETCONF config file is an XML instance document containing >>> the element? I was hoping we could put >>> that in 4741bis. >> ... >> >> Conformance to the protocol should not dictate the format a system >> uses internally. > > +1. > IMO, it is useful for the NETCONF architecture to consider how a device handles a startup sequence from factory-default, or just a normal reboot. SNMP failed to recognize many operational aspects of NM, including the startup config. NETCONF addresses some of it and ignores the rest. Since every server is required to support a copy-config(inline) to its write-target (candidate or running), it seems pretty easy to support the same format for NV-boot, at least at the conceptual level. > In this particular case, as long as on startup produces > the correct XML, it doesn't matter what form the data is stored > internally. > > However, the format of what goes into a URL file used by > isn't specified, but should be (see > http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis#issue-012). > This still just means that the format produced / consumed by the > is well-defined; it doesn't mean that the file format > MUST be the same. > If an XML file from one copy-config doesn't work with copy-config on a different device, then NETCONF fails to meet a very important requirement identified by operators at the IAB NM Workshop -- the one that led to separate in the first place. > > /martin Andy From mbj@tail-f.com Fri Sep 25 14:03: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 4989E3A67F4 for ; Fri, 25 Sep 2009 14:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 T+qPUKIKoyaU for ; Fri, 25 Sep 2009 14:03:07 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 711093A67D3 for ; Fri, 25 Sep 2009 14:03:07 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8CCC976C4F6; Fri, 25 Sep 2009 23:04:18 +0200 (CEST) Date: Fri, 25 Sep 2009 23:04:18 +0200 (CEST) Message-Id: <20090925.230418.168965015.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ABD2C1D.8040506@netconfcentral.com> References: <001b01ca3e15$e64690a0$6801a8c0@oemcomputer> <20090925.222137.52411666.mbj@tail-f.com> <4ABD2C1D.8040506@netconfcentral.com> X-Mailer: Mew version 6.0.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] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 21:03:08 -0000 Andy Bierman wrote: > IMO, it is useful for the NETCONF architecture to consider > how a device handles a startup sequence from factory-default, > or just a normal reboot. SNMP failed to recognize many operational > aspects of NM, including the startup config. NETCONF addresses some > of it and ignores the rest. Since every server is required to support > a copy-config(inline) to its write-target (candidate or running), > it seems pretty easy to support the same format for NV-boot, > at least at the conceptual level. On the conceptual level, absolutely. > > In this particular case, as long as on startup produces > > the correct XML, it doesn't matter what form the data is stored > > internally. > > > > However, the format of what goes into a URL file used by > > isn't specified, but should be (see > > http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis#issue-012). > > This still just means that the format produced / consumed by the > > is well-defined; it doesn't mean that the file format > > MUST be the same. > > > > If an XML file from one copy-config doesn't > work with copy-config on a different device, > then NETCONF fails to meet a very important > requirement identified by operators at the IAB NM Workshop -- > the one that led to separate in the first place. That's what issue 12 above is about. /martin From mbj@tail-f.com Fri Sep 25 14:25: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 99A513A6883 for ; Fri, 25 Sep 2009 14:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 kOeifWdIS01y for ; Fri, 25 Sep 2009 14:25:40 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D9EEC3A6845 for ; Fri, 25 Sep 2009 14:25:39 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A4814616009; Fri, 25 Sep 2009 23:26:50 +0200 (CEST) Date: Fri, 25 Sep 2009 23:26:50 +0200 (CEST) Message-Id: <20090925.232650.21176060.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ABCE1AF.9050106@netconfcentral.com> References: <4ABCD169.9020008@netconfcentral.com> <20090925150706.GA18860@elstar.local> <4ABCE1AF.9050106@netconfcentral.com> X-Mailer: Mew version 6.0.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] review of draft-ietf-netconf-with-defaults-03 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, 25 Sep 2009 21:25:40 -0000 Andy Bierman wrote: > Yes -- I realize now why it is the best for normal use. > Even if a YANG default changes across reboots, the explicit > config doesn't change. Currently, the upgrade rules do not allow a default value to be changed. Do you think it would work to allow that? It is not uncommon that it happens... /martin From andy@netconfcentral.com Fri Sep 25 18:25:15 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 568313A67EA for ; Fri, 25 Sep 2009 18:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.315, 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 6NRAN99hcNHF for ; Fri, 25 Sep 2009 18:25:14 -0700 (PDT) Received: from n70.bullet.mail.sp1.yahoo.com (n70.bullet.mail.sp1.yahoo.com [98.136.44.38]) by core3.amsl.com (Postfix) with SMTP id 94E7C3A659A for ; Fri, 25 Sep 2009 18:25:14 -0700 (PDT) Received: from [216.252.122.216] by n70.bullet.mail.sp1.yahoo.com with NNFMP; 26 Sep 2009 01:26:25 -0000 Received: from [68.142.200.227] by t1.bullet.sp1.yahoo.com with NNFMP; 26 Sep 2009 01:26:25 -0000 Received: from [68.142.201.249] by t8.bullet.mud.yahoo.com with NNFMP; 26 Sep 2009 01:26:25 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 26 Sep 2009 01:26:25 -0000 X-Yahoo-Newman-Id: 186800.75336.bm@omp410.mail.mud.yahoo.com Received: (qmail 53779 invoked from network); 26 Sep 2009 01:26:24 -0000 Received: from ppp-67-126-243-218.dsl.irvnca.pacbell.net (andy@67.126.243.218 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 25 Sep 2009 18:26:24 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: U5sLLN4VM1lrv6I7VRYGsIdxD8h0Z27AiqvwhqKBqrKk_hHSoE2WvIZ_Uel8GJ6xIvAEVXytKPl8IJs7VCa7qzy3ydxlAhhbWHpS0fE4zogixkObsdcqjhxz3vnKv6nyFIc6VDp7sTe2uZYy0bVsTIxSwDLUwqOlKsys0Ksnql21KOWszeZjfezupJbhNUF6t72LUH90OAMlpKHeER4QNn686IzbbknPSHLIvkTwzVaxkxJ6Bri9iznD4yaGA2RaxLNPN4HbVoqi X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ABD6DEB.2090506@netconfcentral.com> Date: Fri, 25 Sep 2009 18:27:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4ABCD169.9020008@netconfcentral.com> <20090925150706.GA18860@elstar.local> <4ABCE1AF.9050106@netconfcentral.com> <20090925.232650.21176060.mbj@tail-f.com> In-Reply-To: <20090925.232650.21176060.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 26 Sep 2009 01:25:15 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Yes -- I realize now why it is the best for normal use. >> Even if a YANG default changes across reboots, the explicit >> config doesn't change. > > Currently, the upgrade rules do not allow a default value to be > changed. Do you think it would work to allow that? It is not > uncommon that it happens... > I brought up the issue that the rules let a refine-stmt change the default in a grouping, but one could argue that the leaf in the grouping is just a template, not an object, so the same rules do not always have to apply. I wish that were the case, because moving between inline and uses versions should be transparent to the syntax and the semantics, but they really aren't. If revisions were mandatory to use and advertise, then it would be reasonably safe to change a default in a new published version. IMO, a standard module would have to go back to Proposed Standard in order to do that. leaf most-of-the-time { type string; } IMO the most likely scenario is no static default, and mandatory=false. Vendors will be reluctant to document their defaults added via deviations. If the new server-assignable=true, then the client may have to rely on get-config with-defaults=report-all to learn the dynamic defaults. > > /martin > Andy From jmh@joelhalpern.com Fri Sep 25 19:39: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 A8AA33A6930 for ; Fri, 25 Sep 2009 19:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.34 X-Spam-Level: X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, 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 iiWf6BOHl1mZ for ; Fri, 25 Sep 2009 19:39:20 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C60A33A67EA for ; Fri, 25 Sep 2009 19:39:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3FBB84305C0; Fri, 25 Sep 2009 19:40:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7F6314305B4; Fri, 25 Sep 2009 19:40:32 -0700 (PDT) Message-ID: <4ABD7F1E.6060104@joelhalpern.com> Date: Fri, 25 Sep 2009 22:40:30 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <4ABCD169.9020008@netconfcentral.com> <20090925150706.GA18860@elstar.local> <4ABCE1AF.9050106@netconfcentral.com> <20090925.232650.21176060.mbj@tail-f.com> <4ABD6DEB.2090506@netconfcentral.com> In-Reply-To: <4ABD6DEB.2090506@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 26 Sep 2009 02:39:21 -0000 As far as I know, if a node is server assignable (and with no default specified), then if the server assigns it a value, then the node is returned in a regular get-config. There is no need for with-defaults because that value is not the value defined by the default clause. At least, that was how I understood the last explantion from Martin. Yours, Joel Andy Bierman wrote: > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Yes -- I realize now why it is the best for normal use. >>> Even if a YANG default changes across reboots, the explicit >>> config doesn't change. >> Currently, the upgrade rules do not allow a default value to be >> changed. Do you think it would work to allow that? It is not >> uncommon that it happens... >> > > I brought up the issue that the rules let a refine-stmt > change the default in a grouping, but one could argue > that the leaf in the grouping is just a template, not > an object, so the same rules do not always have to apply. > > I wish that were the case, because moving between inline > and uses versions should be transparent to the syntax > and the semantics, but they really aren't. > > If revisions were mandatory to use and advertise, then it > would be reasonably safe to change a default in a new > published version. IMO, a standard module would have > to go back to Proposed Standard in order to do that. > > leaf most-of-the-time { > type string; > } > > IMO the most likely scenario is no static default, > and mandatory=false. Vendors will be reluctant to document > their defaults added via deviations. If the > new server-assignable=true, then the client > may have to rely on get-config with-defaults=report-all > to learn the dynamic defaults. > > >> /martin >> > > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From phil@juniper.net Sat Sep 26 12:29:09 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 1EA213A6985 for ; Sat, 26 Sep 2009 12:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 zP1PIeFXpc5g for ; Sat, 26 Sep 2009 12:29:08 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id CB4C33A697A for ; Sat, 26 Sep 2009 12:29:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSr5rzOxUF1dEXIZ0/6+tYEAlOjZyumdq@postini.com; Sat, 26 Sep 2009 12:30:22 PDT 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.375.2; Sat, 26 Sep 2009 12:28:42 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Sep 2009 12:28:42 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Sep 2009 12:28:41 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Sep 2009 12:28:41 -0700 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 n8QJSej42640; Sat, 26 Sep 2009 12:28:40 -0700 (PDT) (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 n8QJGAJE066087; Sat, 26 Sep 2009 19:16:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909261916.n8QJGAJE066087@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4ABD7F1E.6060104@joelhalpern.com> Date: Sat, 26 Sep 2009 15:16:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Sep 2009 19:28:41.0331 (UTC) FILETIME=[8DEE3C30:01CA3EDF] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 26 Sep 2009 19:29:09 -0000 "Joel M. Halpern" writes: >As far as I know, if a node is server assignable (and with no default >specified), then if the server assigns it a value, then the node is >returned in a regular get-config. There is no need for with-defaults >because that value is not the value defined by the default clause. > >At least, that was how I understood the last explantion from Martin. This is exactly correct. Anything that is system-assignable won't it have a default value (nor will it be mandatory). Thanks, Phil From andy@netconfcentral.com Sun Sep 27 10:33: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 4B7313A6923 for ; Sun, 27 Sep 2009 10:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_20=-0.74] 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 MvTlBV-Rp5EG for ; Sun, 27 Sep 2009 10:33:26 -0700 (PDT) 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 693B53A6916 for ; Sun, 27 Sep 2009 10:33:26 -0700 (PDT) Received: (qmail 2663 invoked from network); 27 Sep 2009 17:34:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.126.243.218 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 27 Sep 2009 17:34:40 -0000 X-YMail-OSG: oCer7hMVM1kUO36WRiw9RlGOFIKAytjC0qvk1wWD_npEBKCL4Ryb6N2VcrRkkGaSJ1zcUxufX3GA0JqAaZM45wLJrcz7tECbejD8HDXaRxJCzSDHwM1p.XN62j8p6tP8Cu0nDDyA5tESzfd2H2eWanpfV8dHre8pst0lBrfzYjUQ5hpRlsHgIMDtnZ4hRd3_Kpothid.8cUOIClXp6VGD8n3AZ6D.wVxoDVMQokNoN9ozhjc6LOBJdXis6SrGfBTaqRPnbIDy3Zk9Ili X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ABFA1EA.1030402@netconfcentral.com> Date: Sun, 27 Sep 2009 10:33:30 -0700 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] 2 more confirmed-commit details 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: Sun, 27 Sep 2009 17:33:27 -0000 Hi, IMO, the confirmed-commit procedure is really fuzzy wrt/ applying access control policy. Without any standard ACM, it may be too out of scope to consider, but I'll try anyway: 1) What is the username is effect during the rollback? I assumed the rollback edits are done in the ACM context of the original user who started the confirmed-commit. Is this correct? 2) incremental edits blocking rollback If session 1 started the confirmed-commit, but session 2 extended it by adding some changes, it is possible for the rollback edits to touch subtrees that S2 was authorized to write, but not S1. This should not cause the entire rollback to fail, but the S2-edits cannot be undone. Andy From mbj@tail-f.com Mon Sep 28 00:08: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 5CB0D3A6835 for ; Mon, 28 Sep 2009 00:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 AkkGsRZYqAgB for ; Mon, 28 Sep 2009 00:08:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 76BBB3A67D2 for ; Mon, 28 Sep 2009 00:08:12 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id F28BC76C5D7; Mon, 28 Sep 2009 09:09:28 +0200 (CEST) Date: Mon, 28 Sep 2009 09:09:25 +0200 (CEST) Message-Id: <20090928.090925.25419232.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ABFA1EA.1030402@netconfcentral.com> References: <4ABFA1EA.1030402@netconfcentral.com> X-Mailer: Mew version 6.0.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] 2 more confirmed-commit details 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 Sep 2009 07:08:13 -0000 Andy Bierman wrote: > Hi, > > IMO, the confirmed-commit procedure is really fuzzy wrt/ > applying access control policy. Without any standard ACM, > it may be too out of scope to consider, but I'll try anyway: > > 1) What is the username is effect during the rollback? > > I assumed the rollback edits are done in the ACM context > of the original user who started the confirmed-commit. > Is this correct? > > 2) incremental edits blocking rollback > > If session 1 started the confirmed-commit, but session 2 > extended it by adding some changes, it is possible for > the rollback edits to touch subtrees that S2 was authorized > to write, but not S1. This should not cause the entire rollback > to fail, but the S2-edits cannot be undone. Or maybe some of the S2-edits are undone, i.e. the ones that S1 has access to? What if the resulting db is not valid at this point? If this is how extended confirmed commit is supposed to work with access control, then I prefer to remove the extended confirmed commit feature. Logically, when the first confirmed commit is issued, the db is checkpointed. Extra commits from this point does not affect the checkpoint. If the box reboots it will boot from the checkpointed db. But is this really a logical consequence of having an ACM? The scenario is: S1: edits candidate, does confirmed commit S2: edits candidate, does commit S1: reboots or terminates the session S2's changes are now gone -- this is the potential ACM violation Consider a similar case, w/o candidate: S1: edits running, and does copy-config to startup S2: edits running S1 reboots the box S2's changes are now gone - is this a ACM violation?? /martin From andy@netconfcentral.com Mon Sep 28 01:03: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 0A9D53A6873 for ; Mon, 28 Sep 2009 01:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.286, 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 oaLxeJShwFGa for ; Mon, 28 Sep 2009 01:03:18 -0700 (PDT) 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 D7D7B3A67E2 for ; Mon, 28 Sep 2009 01:03:17 -0700 (PDT) Received: (qmail 63607 invoked from network); 28 Sep 2009 08:04:33 -0000 Received: from ppp-67-126-243-218.dsl.irvnca.pacbell.net (andy@67.126.243.218 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 28 Sep 2009 01:04:32 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: AIEb1o0VM1neDIL51CVRtDYQ32YkO1akXBpO8Dl9LC7qfN_DlARZ92Y6yG1rb5_SyE3yi5FCT_rLz74Di9hr4DAIW33NGix9tgoeXgkKa5Dfccj9x8zsSGYSjsHj9sgbh6_ouPt1niISpQNujbSE8WltQwT9zFwEvP0gb76Kw46QA5Hs9K9COox.cFkYVMt6iRp6YGtf74eT0hFvxfk3CuPgbf40hrDNMo6V0c.JM_byyLVRxpXSx9O8Q89lftGvTwbMFBHWPSnXWPEdpGAFw.fVosvILWFZMv1VCVD88waqe74_Br3GDjduW31jAnFz53hbJBYqd5ifVg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC06DCE.3080909@netconfcentral.com> Date: Mon, 28 Sep 2009 01:03:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> In-Reply-To: <20090928.090925.25419232.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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 Sep 2009 08:03:19 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> IMO, the confirmed-commit procedure is really fuzzy wrt/ >> applying access control policy. Without any standard ACM, >> it may be too out of scope to consider, but I'll try anyway: >> >> 1) What is the username is effect during the rollback? >> >> I assumed the rollback edits are done in the ACM context >> of the original user who started the confirmed-commit. >> Is this correct? >> >> 2) incremental edits blocking rollback >> >> If session 1 started the confirmed-commit, but session 2 >> extended it by adding some changes, it is possible for >> the rollback edits to touch subtrees that S2 was authorized >> to write, but not S1. This should not cause the entire rollback >> to fail, but the S2-edits cannot be undone. > > Or maybe some of the S2-edits are undone, i.e. the ones that S1 has > access to? What if the resulting db is not valid at this point? > > If this is how extended confirmed commit is supposed to work with > access control, then I prefer to remove the extended confirmed commit > feature. Logically, when the first confirmed commit is issued, the db > is checkpointed. Extra commits from this point does not affect the > checkpoint. If the box reboots it will boot from the checkpointed db. > I'm just guessing at how it should work. I don't like the extend-mode with changes. It is not intuitive how the recovery works. I'm not sure access control actually does work in all recovery modes. NETCONF database transactions without locking could be considered a garbage-in/garbage-out corner-case. IMO, the server should not be bothered to try very hard to sort out the wreckage and undo the garbage edits. One approach is to say that the server (superuser) is running the rollback and discard-changes, so it always wins, and therefore the rollback wins over the new edits. > But is this really a logical consequence of having an ACM? The > scenario is: > > S1: edits candidate, does confirmed commit > S2: edits candidate, does commit > S1: reboots or terminates the session > S2's changes are now gone -- this is the potential ACM violation > A rollback gets triggered when commit-timeout expires as well. It is this rollback edit on the altered subtrees that I am wondering about. The reboot rollback falls out for free because the NV-store never happened, so the previous NV-store contents are still in place. > Consider a similar case, w/o candidate: > > S1: edits running, and does copy-config to startup > S2: edits running > S1 reboots the box > S2's changes are now gone - is this a ACM violation?? > You get what you get when you interleave database transactions without any locking. S2 should have known not to commit anything while S1 had a confirmed-commit running. :-) (Of course, this is no way for S2 to know that in the standard, so use locking or be sorry.) If S2 locks candidate or running, then it could be argued that S1 still wins, because the server promised to execute a confirmed-commit before it gave out the lock. It would be nice to clear confirmed-commit in 4741bis. You never realize how under-specified something is until you try to implement it ;-) > > > /martin > Andy From Washam.Fan@huaweisymantec.com Mon Sep 28 07:45: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 68FAB3A69BA for ; Mon, 28 Sep 2009 07:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=-0.162, 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 Hh8stCvNdo8d for ; Mon, 28 Sep 2009 07:45:52 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 3A0543A69B8 for ; Mon, 28 Sep 2009 07:45:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-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 <0KQO00BLKRPPGE10@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Mon, 28 Sep 2009 22:46:38 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KQO00BHORPP9H20@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Mon, 28 Sep 2009 22:46:37 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Mon, 28 Sep 2009 22:46:37 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Mon, 28 Sep 2009 22:46:37 +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: <4AC06DCE.3080909@netconfcentral.com> References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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 Sep 2009 14:45:53 -0000 Hi, ----- Original Message ----- From: Andy Bierman Date: Monday, September 28, 2009 4:06 pm Subject: Re: [Netconf] 2 more confirmed-commit details To: Martin Bjorklund Cc: netconf@ietf.org > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> IMO, the confirmed-commit procedure is really fuzzy wrt/ > >> applying access control policy. Without any standard ACM, > >> it may be too out of scope to consider, but I'll try anyway: > >> > >> 1) What is the username is effect during the rollback? > >> > >> I assumed the rollback edits are done in the ACM context > >> of the original user who started the confirmed-commit. > >> Is this correct? > >> > >> 2) incremental edits blocking rollback > >> > >> If session 1 started the confirmed-commit, but session 2 > >> extended it by adding some changes, it is possible for > >> the rollback edits to touch subtrees that S2 was authorized > >> to write, but not S1. This should not cause the entire rollback > >> to fail, but the S2-edits cannot be undone. > > > > Or maybe some of the S2-edits are undone, i.e. the ones that S1 has > > access to? What if the resulting db is not valid at this point? > > > > If this is how extended confirmed commit is supposed to work with > > access control, then I prefer to remove the extended confirmed commit > > feature. Logically, when the first confirmed commit is issued, the > db > > is checkpointed. Extra commits from this point does not affect the > > checkpoint. If the box reboots it will boot from the checkpointed db. > > > > I'm just guessing at how it should work. > I don't like the extend-mode with changes. > It is not intuitive how the recovery works. > I'm not sure access control actually does work > in all recovery modes. > > NETCONF database transactions without locking > could be considered a garbage-in/garbage-out corner-case. > IMO, the server should not be bothered to try very > hard to sort out the wreckage and undo the garbage edits. +1 The last para in 8.4.1, RFC4741 points it out: For shared configurations, this feature can cause other configuration changes (for example, via other NETCONF sessions) to be inadvertently altered or removed, unless the configuration locking feature is used (in other words, the lock is obtained before the edit-config operation is started). Therefore, it is strongly suggested that in order to use this feature with shared configuration databases, configuration locking should also be used. > One approach is to say that the server (superuser) is > running the rollback and discard-changes, so it always wins, > and therefore the rollback wins over the new edits. > > > But is this really a logical consequence of having an ACM? The > > scenario is: > > > > S1: edits candidate, does confirmed commit > > S2: edits candidate, does commit > > S1: reboots or terminates the session > > S2's changes are now gone -- this is the potential ACM violation > > > > A rollback gets triggered when commit-timeout expires as well. > It is this rollback edit on the altered subtrees that I > am wondering about. The reboot rollback falls out for > free because the NV-store never happened, so the previous NV-store > contents are still in place. > > > > Consider a similar case, w/o candidate: > > > > S1: edits running, and does copy-config to startup > > S2: edits running > > S1 reboots the box > > S2's changes are now gone - is this a ACM violation?? > > > > You get what you get when you interleave database transactions > without any locking. S2 should have known not to commit > anything while S1 had a confirmed-commit running. :-) > (Of course, this is no way for S2 to know that in > the standard, so use locking or be sorry.) > > If S2 locks candidate or running, then it could be argued that > S1 still wins, because the server promised to execute a > confirmed-commit before it gave out the lock. I don't think it is clear that server should execute a confirmed-commit before it gave out the lock in current text, could you point it out for me washam > It would be nice to clear confirmed-commit in 4741bis. > You never realize how under-specified something is > until you try to implement it ;-) > > > > > > > > > /martin > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@netconfcentral.com Mon Sep 28 08:15: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 D388A3A6894 for ; Mon, 28 Sep 2009 08:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.263, 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 jR5q9VwsVXln for ; Mon, 28 Sep 2009 08:15:09 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id BE47F3A6933 for ; Mon, 28 Sep 2009 08:15:09 -0700 (PDT) Received: from [68.142.194.243] by n10.bullet.mail.mud.yahoo.com with NNFMP; 28 Sep 2009 15:16:28 -0000 Received: from [68.142.201.247] by t1.bullet.mud.yahoo.com with NNFMP; 28 Sep 2009 15:16:28 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 28 Sep 2009 15:16:28 -0000 X-Yahoo-Newman-Id: 236852.42316.bm@omp408.mail.mud.yahoo.com Received: (qmail 58096 invoked from network); 28 Sep 2009 15:16:27 -0000 Received: from ppp-67-126-243-218.dsl.irvnca.pacbell.net (andy@67.126.243.218 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 28 Sep 2009 08:16:27 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: LNdn6eEVM1mShKxhaDESh1g.F3TO8hpKaw94QCa9lyXpynjUKJgcDbMEKM8gVQMZ9PjfpU8DmrOHiXJnZHRm0FnIj.WhEee2I5ZBt571Z27z0foJSjKvfWIpOGnViEvQJq.raQB97jbmI2zvCl.j37ZtSaUfGgsLiNTmV0RCVK1HTaR9itSbeKIPaoy.XdkH6.6sU_UqB5E4Gp5OOMIoLhzNYcokCuWrKl.My4QM.TjN5wY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC0D384.1020808@netconfcentral.com> Date: Mon, 28 Sep 2009 08:17:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: WashamFan References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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 Sep 2009 15:15:10 -0000 WashamFan wrote: > Hi, > > ----- Original Message ----- > From: Andy Bierman > Date: Monday, September 28, 2009 4:06 pm > Subject: Re: [Netconf] 2 more confirmed-commit details > To: Martin Bjorklund > Cc: netconf@ietf.org > > >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> IMO, the confirmed-commit procedure is really fuzzy wrt/ >>>> applying access control policy. Without any standard ACM, >>>> it may be too out of scope to consider, but I'll try anyway: >>>> >>>> 1) What is the username is effect during the rollback? >>>> >>>> I assumed the rollback edits are done in the ACM context >>>> of the original user who started the confirmed-commit. >>>> Is this correct? >>>> >>>> 2) incremental edits blocking rollback >>>> >>>> If session 1 started the confirmed-commit, but session 2 >>>> extended it by adding some changes, it is possible for >>>> the rollback edits to touch subtrees that S2 was authorized >>>> to write, but not S1. This should not cause the entire rollback >>>> to fail, but the S2-edits cannot be undone. >>> Or maybe some of the S2-edits are undone, i.e. the ones that S1 has >>> access to? What if the resulting db is not valid at this point? >>> >>> If this is how extended confirmed commit is supposed to work with >>> access control, then I prefer to remove the extended confirmed commit >>> feature. Logically, when the first confirmed commit is issued, the >> db >>> is checkpointed. Extra commits from this point does not affect the >>> checkpoint. If the box reboots it will boot from the checkpointed db. >>> >> I'm just guessing at how it should work. >> I don't like the extend-mode with changes. >> It is not intuitive how the recovery works. >> I'm not sure access control actually does work >> in all recovery modes. >> >> NETCONF database transactions without locking >> could be considered a garbage-in/garbage-out corner-case. >> IMO, the server should not be bothered to try very >> hard to sort out the wreckage and undo the garbage edits. > > +1 > The last para in 8.4.1, RFC4741 points it out: > > For shared configurations, this feature can cause other configuration > changes (for example, via other NETCONF sessions) to be inadvertently > altered or removed, unless the configuration locking feature is used > (in other words, the lock is obtained before the edit-config > operation is started). Therefore, it is strongly suggested that in > order to use this feature with shared configuration databases, > configuration locking should also be used. > >> One approach is to say that the server (superuser) is >> running the rollback and discard-changes, so it always wins, >> and therefore the rollback wins over the new edits. >> >>> But is this really a logical consequence of having an ACM? The >>> scenario is: >>> >>> S1: edits candidate, does confirmed commit >>> S2: edits candidate, does commit >>> S1: reboots or terminates the session >>> S2's changes are now gone -- this is the potential ACM violation >>> >> A rollback gets triggered when commit-timeout expires as well. >> It is this rollback edit on the altered subtrees that I >> am wondering about. The reboot rollback falls out for >> free because the NV-store never happened, so the previous NV-store >> contents are still in place. >> >> >>> Consider a similar case, w/o candidate: >>> >>> S1: edits running, and does copy-config to startup >>> S2: edits running >>> S1 reboots the box >>> S2's changes are now gone - is this a ACM violation?? >>> >> You get what you get when you interleave database transactions >> without any locking. S2 should have known not to commit >> anything while S1 had a confirmed-commit running. :-) >> (Of course, this is no way for S2 to know that in >> the standard, so use locking or be sorry.) >> >> If S2 locks candidate or running, then it could be argued that >> S1 still wins, because the server promised to execute a >> confirmed-commit before it gave out the lock. > > I don't think it is clear that server should execute a confirmed-commit > before it gave out the lock in current text, could you point it out > for me > As I said in the email, the draft is unclear and it doesn't say anything whatsoever about access control or rollback when locked by another session. We are trying to reach consensus on the need for any new text. > washam > Andy >> It would be nice to clear confirmed-commit in 4741bis. >> You never realize how under-specified something is >> until you try to implement it ;-) >> >> >> >>> >>> /martin >>> >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > From wjhns1@hardakers.net Mon Sep 28 09:04: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 B3CC03A659B for ; Mon, 28 Sep 2009 09:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOc1gmY938rV for ; Mon, 28 Sep 2009 09:04:24 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id C4BB73A6358 for ; Mon, 28 Sep 2009 09:04:23 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id BA00798318; Mon, 28 Sep 2009 09:05:41 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Organization: Sparta References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> Date: Mon, 28 Sep 2009 09:05:41 -0700 In-Reply-To: <4AC06DCE.3080909@netconfcentral.com> (Andy Bierman's message of "Mon, 28 Sep 2009 01:03:26 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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 Sep 2009 16:04:24 -0000 >>>>> On Mon, 28 Sep 2009 01:03:26 -0700, Andy Bierman said: AB> One approach is to say that the server (superuser) is AB> running the rollback and discard-changes, so it always wins, AB> and therefore the rollback wins over the new edits. That's not a good solution and provides a huge number of problems as well. The correct thing to do, if you've decided that commit/rollback features are unsafe without a lock, is to require a lock in order to use them. As I've said before, the biggest issues I have with netconf and security is that it's a mix of both atomic and subatomic operations that conflict when you try to apply it to scalable multi-operator scenarios. To get around the core issues you need to either treat the whole thing as a single-user-at-a-time solution (locking, copy-config, commit, rollback, etc) or a proper multi-user-at-a-time solution (partial-lock, patch, patch-commit, etc but no global copy-config). Right now there is a mix of two entirely different types of operations. -- Wes Hardaker Cobham Analytic Solutions From andy@netconfcentral.com Mon Sep 28 09:40: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 1BECB3A659B for ; Mon, 28 Sep 2009 09:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 slnJOp2oUtjM for ; Mon, 28 Sep 2009 09:40:11 -0700 (PDT) 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 C26013A69A3 for ; Mon, 28 Sep 2009 09:40:09 -0700 (PDT) Received: (qmail 26664 invoked from network); 28 Sep 2009 16:41:26 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.126.243.218 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 28 Sep 2009 16:41:26 -0000 X-YMail-OSG: Nm7.vY4VM1mEooJUq0Hi9hgpfa0JD6BCCMyc1IOXyIYvNJbhNhFiRZWpbwZwy3W6UjXeyUqMX1NYnUQMyqCB6SZZiqfuzKMSnaXl.SRrQLEhyfm4L6tQg0t2BgG5WwYRRh3RGNtEqxHL_6kM_c0geYtlpUUHCR_TouOV9OIX65ETBa1qaQS.Rpg5PL8sQt1UI5Y6bGVkOvBC3SpXDoQexuNmgPREpWJwBv0vORru4GC1ho3Zh.p9nqpHKFgifxIW37x9mItsuHp27Y7JpYwdoORcbbgZi0BssPb_.xep0iutI.x61DKpoPs7XYMwg3P4UvRVRe7n6pvjAi2YyJEMO6Up X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC0E76F.2040806@netconfcentral.com> Date: Mon, 28 Sep 2009 09:42:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Wes Hardaker References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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 Sep 2009 16:40:13 -0000 Wes Hardaker wrote: >>>>>> On Mon, 28 Sep 2009 01:03:26 -0700, Andy Bierman said: > > AB> One approach is to say that the server (superuser) is > AB> running the rollback and discard-changes, so it always wins, > AB> and therefore the rollback wins over the new edits. > > That's not a good solution and provides a huge number of problems as > well. > > The correct thing to do, if you've decided that commit/rollback features > are unsafe without a lock, is to require a lock in order to use them. > > As I've said before, the biggest issues I have with netconf and security > is that it's a mix of both atomic and subatomic operations that conflict > when you try to apply it to scalable multi-operator scenarios. To get > around the core issues you need to either treat the whole thing as a > single-user-at-a-time solution (locking, copy-config, commit, rollback, > etc) or a proper multi-user-at-a-time solution (partial-lock, patch, > patch-commit, etc but no global copy-config). Right now there is a mix > of two entirely different types of operations. > The NETCONF WG decided locking should be optional-to-use, so your suggestion won't work. I am not going to worry too much about GIGO. The standard doesn't have any access control at all, so every server can do what they want. SNMP never had any locking at all, and that hasn't seemed to cause many problems, or it would have been forced to add locking at some point. Locks are like traffic lights. If you ignore them, you rely on random events to prevent collisions. IMO, the standard should not waste a lot of effort describing how all servers must clean up the wreckage of bad database usage. Andy From root@core3.amsl.com Mon Sep 28 09:45:01 2009 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C24BC3A69C4; Mon, 28 Sep 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090928164501.C24BC3A69C4@core3.amsl.com> Date: Mon, 28 Sep 2009 09:45:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-08.txt 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 Sep 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Monitoring Schema Author(s) : M. Scott, M. Bjorklund Filename : draft-ietf-netconf-monitoring-08.txt Pages : 30 Date : 2009-09-28 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-monitoring-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-28094229.I-D@ietf.org> --NextPart-- From MARKSCOT@nortel.com Mon Sep 28 10:04:06 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 202133A691C for ; Mon, 28 Sep 2009 10:04:06 -0700 (PDT) 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 zGXSjL5-FOT0 for ; Mon, 28 Sep 2009 10:04:05 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 031133A67FC for ; Mon, 28 Sep 2009 10:04:04 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8SH5IF20393 for ; Mon, 28 Sep 2009 17:05:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 28 Sep 2009 13:05:15 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1A784EC0@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-netconf-monitoring-08 Thread-Index: AcpAWt0Gh4v6eHUUQciB1mosIrSgZAAADGHQ From: "Mark Scott" To: "NETCONF" Subject: [Netconf] FW: New Version Notification for draft-ietf-netconf-monitoring-08 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 Sep 2009 17:04:06 -0000 SGVsbG8sDQoNCkEgbmV3IHZlcnNpb24gKHY4KSBvZiB0aGUgTkVUQ09ORiBNb25pdG9yaW5nIFNj aGVtYSBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQuDQoNClRoaXMgdmVyc2lvbiBhZGRyZXNzZXMgYWN0 aW9uIGl0ZW1zIGZyb20gSUVURjc1IGFuZCBtYWlsaW5nIGxpc3QgY29tbWVudHMuICBNb3N0IHNp Z25pZmljYW50IGlzIHRoZSBkZWNpc2lvbiB0byBhZG9wdCBZQU5HIGFzIG5vcm1hdGl2ZSBmb3Ig dGhpcyBkcmFmdC4NCg0KQXMgYSByZXN1bHQgdGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQg ZGVwZW5kcyBvbjoNCiAtIFdHTEMgdXBkYXRlcyAoaWYgcmVxdWlyZWQpDQogLSB1cGRhdGVzIHRv IHRoZSBub3JtYXRpdmUgbW9kZWwgYXMgcmVzdWx0IG9mIG5ldG1vZCBZQU5HIChpZiByZXF1aXJl ZCkNCiAtIGRhdGEgb3JnYW5pemF0aW9uIGNoYW5nZXMgaWYgV0cgYWRvcHRzIGEgbmV3IGRhdGEg aGllcmFyY2h5IGZvciBuZXRtb2QgKHRoaXMgZHJhZnQgdXNlcyAiL25ldGNvbmYtc3RhdGUvIikN Cg0KVGhlIFhNTCBTY2hlbWEgb2YgdGhlIG1vbml0b3JpbmcgbW9kZWwgYW5kIElQIGhvc3QgZGVm aW5pdGlvbiBoYXZlIGJlZW4gcmVtb3ZlZC4NCg0KUGxlYXNlIGRpcmVjdCBhbnkgY29tbWVudHMg b24gdGhpcyB2ZXJzaW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QuDQoNCmNoZWVycywNCk1hcmsNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBU b29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgU2VwdGVt YmVyIDI4LCAyMDA5IDEyOjQyIFBNDQpUbzogU2NvdHQsIE1hcmsgKENBUjoyTjAwKQ0KQ2M6IG1i akB0YWlsLWYuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWlldGYtbmV0Y29uZi1tb25pdG9yaW5nLTA4IA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1pZXRmLW5ldGNvbmYtbW9uaXRvcmluZy0wOC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bHkg c3VibWl0dGVkIGJ5IE1hcmsgU2NvdHQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWlldGYtbmV0Y29uZi1tb25pdG9yaW5nDQpSZXZpc2lvbjoJ IDA4DQpUaXRsZToJCSBORVRDT05GIE1vbml0b3JpbmcgU2NoZW1hDQpDcmVhdGlvbl9kYXRlOgkg MjAwOS0wOS0yOA0KV0cgSUQ6CQkgbmV0Y29uZg0KTnVtYmVyX29mX3BhZ2VzOiAzMA0KDQpBYnN0 cmFjdDoNClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIE5FVENPTkYgZGF0YSBtb2RlbCB0byBiZSB1 c2VkIHRvIG1vbml0b3IgdGhlDQpORVRDT05GIHByb3RvY29sLiAgVGhlIG1vbml0b3JpbmcgZGF0 YSBtb2RlbCBpbmNsdWRlcyBpbmZvcm1hdGlvbg0KYWJvdXQgTkVUQ09ORiBkYXRhc3RvcmVzLCBz ZXNzaW9ucywgbG9ja3MgYW5kIHN0YXRpc3RpY3MuICBUaGlzIGRhdGENCmZhY2lsaXRhdGVzIHRo ZSBtYW5hZ2VtZW50IG9mIGEgTkVUQ09ORiBzZXJ2ZXIuICBUaGlzIGRvY3VtZW50IGFsc28NCmRl ZmluZXMgbWV0aG9kcyBmb3IgTkVUQ09ORiBjbGllbnRzIHRvIGRpc2NvdmVyIGRhdGEgbW9kZWxz IHN1cHBvcnRlZA0KYnkgYSBORVRDT05GIHNlcnZlciBhbmQgZGVmaW5lcyBhIG5ldyBORVRDT05G IDxnZXQtc2NoZW1hPiBvcGVyYXRpb24NCnRvIHJldHJpZXZlIHRoZW0uDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0K From andy@netconfcentral.com Mon Sep 28 10:04:47 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 72B493A69B1 for ; Mon, 28 Sep 2009 10:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=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 P6WpBUTSG1Aq for ; Mon, 28 Sep 2009 10:04:46 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id CD8BE3A6828 for ; Mon, 28 Sep 2009 10:04:46 -0700 (PDT) Received: (qmail 59629 invoked from network); 28 Sep 2009 17:06:04 -0000 Received: from ppp-67-126-243-218.dsl.irvnca.pacbell.net (andy@67.126.243.218 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 28 Sep 2009 10:06:03 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: bzVV6RoVM1lc1waxJJMxNOsg6oFeuOH9pQeUZLyCRVnhW0LgcwbfzEUgeeAFoj8r91CiAjBGCQpMyC1YVb1x06RhotvPFt3jkSG9f2Qyv6je359UvDZ9M7D4BJ9jINhBQ4UZfcZLpSUtOE0a4qPKgSnPFtrRCvez4IpIxNzOG7qyJkaPRlccouw0_jw5uT8M4gBEHmrEzpd2SCQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC0ED35.3070404@netconfcentral.com> Date: Mon, 28 Sep 2009 10:07:01 -0700 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] comments on monitoring-08 draft 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 Sep 2009 17:04:47 -0000 Hi, I noticed that the 'transport' identity was replaced with a 'session-type' identity, and now the /sessions/session/transport leaf has been changed to a session-type leaf. Yet no new standard identities were added, and no semantics were altered. I object to this gratuitous incompatible change with -07. It looks like some tweaks to support proprietary data models. IMO, the vendor should augment the entry with a different leaf. I really want to know the transport, not some meaningless 'session type' that happens to look like a transport type. Also, I thought we were going to make the get-schema/input/version parameter optional, and add a default=YANG to the format parameter. Instead the /sessions/session/loginTime was changed to mandatory. Andy From j.schoenwaelder@jacobs-university.de Mon Sep 28 12:03: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 6D8243A6840 for ; Mon, 28 Sep 2009 12:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_40=-0.185, 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 XMjw-MYADN0I for ; Mon, 28 Sep 2009 12:03:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8555C28C120 for ; Mon, 28 Sep 2009 12:03:02 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CBF2BC0030; Mon, 28 Sep 2009 21:04:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TwMzvGTPGPoi; Mon, 28 Sep 2009 21:04:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0784C0017; Mon, 28 Sep 2009 21:04:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C4087D06078; Mon, 28 Sep 2009 21:04:18 +0200 (CEST) Date: Mon, 28 Sep 2009 21:04:18 +0200 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20090928190418.GB23637@elstar.local> Mail-Followup-To: Mark Scott , NETCONF References: <085091CB2CA14E4B8B163FFC37C84E9D1A784EC0@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D1A784EC0@zcarhxm0.corp.nortel.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF Subject: [Netconf] Comments on draft-ietf-netconf-monitoring-08 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: Mon, 28 Sep 2009 19:03:07 -0000 On Mon, Sep 28, 2009 at 07:05:15PM +0200, Mark Scott wrote: > This version addresses action items from IETF75 and mailing list > comments. Most significant is the decision to adopt YANG as > normative for this draft. I still do not like the capitalized identifiers. Furthermore, we should import relevant types from ietf-netconf (SessionId can clearly be imported). The NETCONFDatastoreType should probably be provided by ietf-netconf (after renaming). I am wondering why you use zero-based-counter32 and not just counter32. Do we worry about the fact that this might rollover and become ambiguous? I think all definitions should have proper descriptions. Not all have them. What is the reason to define groupings inline? It is unclear what the "NETCONF server process" is on implementations that use multiple server processes working together, e.g. one frontend forked from sshd and a backend interfacing to potentially even more processes. I would appreciate a more detailed description which counters I can derive from the counters in the YANG module. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Washam.Fan@huaweisymantec.com Mon Sep 28 22:20: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 C08B13A6A3E for ; Mon, 28 Sep 2009 22:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_20=-0.74] 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 RiPmbc7CN0Gy for ; Mon, 28 Sep 2009 22:20:15 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 877F53A67B1 for ; Mon, 28 Sep 2009 22:20:15 -0700 (PDT) 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 <0KQP00I5GW79VO50@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 29 Sep 2009 13:21:09 +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 <0KQP004N4W78DG10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 29 Sep 2009 13:21:08 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 29 Sep 2009 13:21:08 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 29 Sep 2009 13:21:08 +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: <4AC0E76F.2040806@netconfcentral.com> References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> <4AC0E76F.2040806@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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, 29 Sep 2009 05:20:18 -0000 > Wes Hardaker wrote: > >>>>>> On Mon, 28 Sep 2009 01:03:26 -0700, Andy Bierman > said: > > > > AB> One approach is to say that the server (superuser) is > > AB> running the rollback and discard-changes, so it always wins, > > AB> and therefore the rollback wins over the new edits. > > > > That's not a good solution and provides a huge number of problems as > > well. > > > > The correct thing to do, if you've decided that commit/rollback features > > are unsafe without a lock, is to require a lock in order to use them. > > > > As I've said before, the biggest issues I have with netconf and security > > is that it's a mix of both atomic and subatomic operations that conflict > > when you try to apply it to scalable multi-operator scenarios. To > get > > around the core issues you need to either treat the whole thing as > a > > single-user-at-a-time solution (locking, copy-config, commit, rollback, > > etc) or a proper multi-user-at-a-time solution (partial-lock, patch, > > patch-commit, etc but no global copy-config). Right now there is a > mix > > of two entirely different types of operations. > > > > > The NETCONF WG decided locking should be optional-to-use, > so your suggestion won't work. Sorry, I don't think so. global lock is mandatory-to-implement and should be used in appropriate case. Actually, I totally agree with Wes that use lock when you think it is neccessary. > I am not going to worry too much about GIGO. > The standard doesn't have any access control at all, > so every server can do what they want. > > SNMP never had any locking at all, and that > hasn't seemed to cause many problems, or it would have > been forced to add locking at some point. I don't think locking means much to SNMP alone. Cause SNMP SET seldom configures the whole box but does set some features. But locking makes sense to SNMP where let's say, Netconf, CLI, even Cops and SNMP reside in the same device and all be active. Actually we had done this effort by draft-fan-meng-snmp-lock washam > Locks are like traffic lights. If you ignore them, > you rely on random events to prevent collisions. > IMO, the standard should not waste a lot of effort > describing how all servers must clean up the wreckage > of bad database usage. > > > Andy From andy@netconfcentral.com Mon Sep 28 22:45:52 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 B8E3D28C0EC for ; Mon, 28 Sep 2009 22:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 XgMQ+xzMBS1w for ; Mon, 28 Sep 2009 22:45:51 -0700 (PDT) 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 AA8BF3A6A47 for ; Mon, 28 Sep 2009 22:45:51 -0700 (PDT) Received: (qmail 48003 invoked from network); 29 Sep 2009 05:47:09 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.81.206 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 29 Sep 2009 05:47:09 -0000 X-YMail-OSG: 6AfpoX8VM1lEUSJsgELUwKKriZ098ZohTRJZS8qh2vwaszHS0PJDd1Z.GPOHbA8Sd0H_ngP_5gUm_CH3C8nYwkpqho2QiHyjyAq3PomerDkM7RG77wjHRselTw3iUkWr.4JlSPH9G2Rk9jWhZnnyXL8RLHd3JFp3_txb1QNDFJfe6Nzgy3P84L9.MA5Vgtfiu0bSpOozTpwRdOyfx4mG94aZ7yM4ufheVeMbGWsdedCIo9RINYQxgaXPXjAubS8nr2.FK1NB7cpvkamIMspbfpj9MEfJomdndqZCPjsQfY8ttbz7HYdIZl4eipZPKapNciO_QZn48B3v X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC19F98.7060102@netconfcentral.com> Date: Mon, 28 Sep 2009 22:48:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: WashamFan References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> <4AC0E76F.2040806@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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, 29 Sep 2009 05:45:52 -0000 WashamFan wrote: >> Wes Hardaker wrote: >> >>>>>> On Mon, 28 Sep 2009 01:03:26 -0700, Andy Bierman >> said: >> > >> > AB> One approach is to say that the server (superuser) is >> > AB> running the rollback and discard-changes, so it always wins, >> > AB> and therefore the rollback wins over the new edits. >> > >> > That's not a good solution and provides a huge number of problems as >> > well. >> > >> > The correct thing to do, if you've decided that commit/rollback features >> > are unsafe without a lock, is to require a lock in order to use them. >> > >> > As I've said before, the biggest issues I have with netconf and security >> > is that it's a mix of both atomic and subatomic operations that conflict >> > when you try to apply it to scalable multi-operator scenarios. To >> get >> > around the core issues you need to either treat the whole thing as >> a >> > single-user-at-a-time solution (locking, copy-config, commit, rollback, >> > etc) or a proper multi-user-at-a-time solution (partial-lock, patch, >> > patch-commit, etc but no global copy-config). Right now there is a >> mix >> > of two entirely different types of operations. >> > >> >> >> The NETCONF WG decided locking should be optional-to-use, >> so your suggestion won't work. > > Sorry, I don't think so. global lock is mandatory-to-implement > and should be used in appropriate case. Actually, I totally agree > with Wes that use lock when you think it is neccessary. > Where does 4741bis say that clients MUST use locking? Or where does it say the server is allowed to return an error for edit-config, commit, etc. if the database is not locked and the PDUs are well-formed, and authorized? If the operator knows nobody else will be editing the database over some known time interval, then locking will not matter. It is up to the operator to decide to use locking, not the server. >> I am not going to worry too much about GIGO. >> The standard doesn't have any access control at all, >> so every server can do what they want. >> >> SNMP never had any locking at all, and that >> hasn't seemed to cause many problems, or it would have >> been forced to add locking at some point. > > I don't think locking means much to SNMP alone. Cause > SNMP SET seldom configures the whole box but does > set some features. But locking makes sense to SNMP > where let's say, Netconf, CLI, even Cops and SNMP > reside in the same device and all be active. Actually we > had done this effort by draft-fan-meng-snmp-lock > there is nothing in SNMP to prevent one NMS from setting a MIB object at the same time as another NMS. It has nothing to do with the number of access methods, but rather the number of concurrent database writers. > washam Andy > >> Locks are like traffic lights. If you ignore them, >> you rely on random events to prevent collisions. >> IMO, the standard should not waste a lot of effort >> describing how all servers must clean up the wreckage >> of bad database usage. >> >> >> Andy > > From Washam.Fan@huaweisymantec.com Mon Sep 28 23:05:09 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 9B68828C129 for ; Mon, 28 Sep 2009 23:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.100, 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 iw2MXjlAxAvz for ; Mon, 28 Sep 2009 23:05:05 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 4F4A128C0E3 for ; Mon, 28 Sep 2009 23:05:00 -0700 (PDT) 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 <0KQP002Q6Y9PUI00@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Tue, 29 Sep 2009 14:05:49 +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 <0KQP004PCY9PI010@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 29 Sep 2009 14:05:49 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 29 Sep 2009 14:05:49 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 29 Sep 2009 14:05:49 +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: <4AC19F98.7060102@netconfcentral.com> References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> <4AC0E76F.2040806@netconfcentral.com> <4AC19F98.7060102@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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, 29 Sep 2009 06:05:09 -0000 > >> > AB> One approach is to say that the server (superuser) is > >> > AB> running the rollback and discard-changes, so it always wins, > >> > AB> and therefore the rollback wins over the new edits. > >> > > >> > That's not a good solution and provides a huge number of > problems as > >> > well. > >> > > >> > The correct thing to do, if you've decided that commit/rollback > features > >> > are unsafe without a lock, is to require a lock in order to use > them. > >> > > >> > As I've said before, the biggest issues I have with netconf and > security > >> > is that it's a mix of both atomic and subatomic operations that > conflict > >> > when you try to apply it to scalable multi-operator scenarios. > To > >> get > >> > around the core issues you need to either treat the whole thing > as > >> a > >> > single-user-at-a-time solution (locking, copy-config, commit, rollback, > >> > etc) or a proper multi-user-at-a-time solution (partial-lock, patch, > >> > patch-commit, etc but no global copy-config). Right now there > is a > >> mix > >> > of two entirely different types of operations. > >> > > >> > >> > >> The NETCONF WG decided locking should be optional-to-use, > >> so your suggestion won't work. > > > > Sorry, I don't think so. global lock is mandatory-to-implement > > and should be used in appropriate case. Actually, I totally agree > > with Wes that use lock when you think it is neccessary. > > > > Where does 4741bis say that clients MUST use locking? > Or where does it say the server is allowed to > return an error for edit-config, commit, etc. > if the database is not locked and the PDUs are > well-formed, and authorized? > If the operator knows nobody else will be editing the database > over some known time interval, then locking will not matter. > It is up to the operator to decide to use locking, not the server. That is what I was trying to say. I just meant, locking is chosen by the client, there is no responsibility for the server to guarantee atomicity of , transaction > >> I am not going to worry too much about GIGO. > >> The standard doesn't have any access control at all, > >> so every server can do what they want. > >> > >> SNMP never had any locking at all, and that > >> hasn't seemed to cause many problems, or it would have > >> been forced to add locking at some point. > > > > I don't think locking means much to SNMP alone. Cause > > SNMP SET seldom configures the whole box but does > > set some features. But locking makes sense to SNMP > > where let's say, Netconf, CLI, even Cops and SNMP > > reside in the same device and all be active. Actually we > > had done this effort by draft-fan-meng-snmp-lock > > > > there is nothing in SNMP to prevent one NMS > from setting a MIB object at the same time as another NMS. > It has nothing to do with the number of access methods, > but rather the number of concurrent database writers. Agreed. But I am not sure how it matters in reality. Since Netconf defines locking which would imapct SNMP, locking problem to SNMP might arise in this case. Currently, this issue does not concern people. washam From wjhns1@hardakers.net Tue Sep 29 06:07: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 9F3073A6AA9 for ; Tue, 29 Sep 2009 06:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOSAFBsQAukh for ; Tue, 29 Sep 2009 06:07:36 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 718F93A6AA3 for ; Tue, 29 Sep 2009 06:07:36 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 5AB4698449; Tue, 29 Sep 2009 06:08:56 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Organization: Sparta References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> <4AC0E76F.2040806@netconfcentral.com> Date: Tue, 29 Sep 2009 06:08:55 -0700 In-Reply-To: <4AC0E76F.2040806@netconfcentral.com> (Andy Bierman's message of "Mon, 28 Sep 2009 09:42:23 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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, 29 Sep 2009 13:07:37 -0000 >>>>> On Mon, 28 Sep 2009 09:42:23 -0700, Andy Bierman said: AB> The NETCONF WG decided locking should be optional-to-use, AB> so your suggestion won't work. I certainly understand that view point. But does that mean that no future feature can depend on or require it to be used? Though in terms of commit/rollback, it's not exactly a "future" feature. AB> I am not going to worry too much about GIGO. AB> The standard doesn't have any access control at all, AB> so every server can do what they want. Designing a protocol without worrying about access control, whether it exists at the moment or not, will certainly insert protocol operations that turn out to be safe when access control is eventually applied to the problem. I fail to see how this is a safe attitude to take. AB> SNMP never had any locking at all, and that AB> hasn't seemed to cause many problems, or it would have AB> been forced to add locking at some point. SNMP was a much more simple protocol that didn't have commit and rollback either. If it did, similar issues may have resulted. SNMP didn't have notions of global config that you could copy around. It never had to worry about the fact that different users might need to issue copy commands to move entire config sets around that they may not even have access rights to modify let alone view. It would certainly be easier if you simply declared that netconf was never to have any sort of access control and was to be treated as a root-only protocol, but no one has ever tried to declare that and in fact many people have hinted (yourself included) that access control is an eventual goal. AB> Locks are like traffic lights. If you ignore them, AB> you rely on random events to prevent collisions. Which is why laws exist saying you can't do that. Somehow, though, in NETCONF you're fine with traffic lights being optional and fine with them being merely advisory. AB> IMO, the standard should not waste a lot of effort describing how AB> all servers must clean up the wreckage of bad database usage. The issue, to me, isn't wreckage of bad data. It's how such oddities of the protocol can be used by nefarious people to achieve goals beyond their assigned capabilities. If you truly believe that netconf shouldn't have access control, then you should write a draft that defines authentication = authorization and see if it's accepted. Maybe it'd be accepted as the best path forward since it would certainly remove a lot of the issues that come up. At a cost of course. -- Wes Hardaker Cobham Analytic Solutions From phil@juniper.net Tue Sep 29 07:03:51 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 0B4343A6ACD for ; Tue, 29 Sep 2009 07:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 9GI+JdZ0ZifW for ; Tue, 29 Sep 2009 07:03:50 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id D416C3A6AC9 for ; Tue, 29 Sep 2009 07:03:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSsIUEX0nODl4ZTC9ruZ2yx+YcplSN4U0@postini.com; Tue, 29 Sep 2009 07:05:08 PDT 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.375.2; Tue, 29 Sep 2009 06:55:18 -0700 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, 29 Sep 2009 06:55:18 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Sep 2009 06:55:18 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Sep 2009 06:55:17 -0700 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 n8TDtHj56307; Tue, 29 Sep 2009 06:55:17 -0700 (PDT) (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 n8TDgivb012223; Tue, 29 Sep 2009 13:42:44 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909291342.n8TDgivb012223@idle.juniper.net> To: Wes Hardaker In-Reply-To: Date: Tue, 29 Sep 2009 09:42:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Sep 2009 13:55:17.0643 (UTC) FILETIME=[7A0AEDB0:01CA410C] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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, 29 Sep 2009 14:03:51 -0000 Wes Hardaker writes: >Which is why laws exist saying you can't do that. Somehow, though, in >NETCONF you're fine with traffic lights being optional and fine with >them being merely advisory. I see it more as arguing over traffic lights in, say, 1910, when the bigger issues are getting the cows out of the road and making sure that all the car makers are using the same fuel. If you can't get the cows out of the road, you aren't going anywhere, and if you can't get the fuel, your model-T will end up being towed by a horse: http://www.strangecosmos.com/images/content/117027.jpg or worse: http://farm4.static.flickr.com/3537/3418988849_3e62a077ea.jpg >If you truly believe that netconf shouldn't have access control, then >you should write a draft that defines authentication = authorization and >see if it's accepted. Maybe it'd be accepted as the best path forward >since it would certainly remove a lot of the issues that come up. At a >cost of course. I don't think anyone is suggesting this. I think the understanding is that the server has an access control mechanism that allows differing users to read and write differing parts of the configuration. How this is specified and how it is learned does not seem sufficiently interesting to anyone to push them into making a draft and getting the working group behind it. IMHO there are more important issues ahead of us. To keep with the auto metaphor, this would be like trying to set up the DMV before people can drive cars down the road. Thanks, Phil From andy@netconfcentral.com Tue Sep 29 07:30: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 6B19D3A6992 for ; Tue, 29 Sep 2009 07:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 ZatO5HgySPht for ; Tue, 29 Sep 2009 07:30:00 -0700 (PDT) Received: from n16.bullet.mail.mud.yahoo.com (n16.bullet.mail.mud.yahoo.com [68.142.206.43]) by core3.amsl.com (Postfix) with SMTP id 5AD593A6989 for ; Tue, 29 Sep 2009 07:30:00 -0700 (PDT) Received: from [68.142.200.227] by n16.bullet.mail.mud.yahoo.com with NNFMP; 29 Sep 2009 14:31:19 -0000 Received: from [68.142.201.66] by t8.bullet.mud.yahoo.com with NNFMP; 29 Sep 2009 14:31:19 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 29 Sep 2009 14:31:04 -0000 X-Yahoo-Newman-Id: 769112.90972.bm@omp418.mail.mud.yahoo.com Received: (qmail 63185 invoked from network); 29 Sep 2009 14:31:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.81.206 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 29 Sep 2009 14:31:03 -0000 X-YMail-OSG: ke_PCG8VM1k7KhmsXIo4MYnIqWJnDqc407dtX4ExUe.ec9beCLQktZqN4oWa8C7CvR9EkVgGYYE6sAV3MbQkrXrGArVnNrXQUiNaOevvSHfAJZX2m7fvoJUJXduCGyDKGJnKcFBYwYZyxvJOBlgPAz0GDiePDleF9XjXlEg8LIk4.ys7T_y4BueZr5FSsPPnb3DbnhF7vZiZn3Rr3lYJqjTVIa6b5YpSvBuUBiQEK7Ws5IVLcQS_IRqjXPHkarHiIlueSxbVCvQL X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC21A66.7070503@netconfcentral.com> Date: Tue, 29 Sep 2009 07:32:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Wes Hardaker References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> <4AC0E76F.2040806@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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, 29 Sep 2009 14:30:01 -0000 Wes Hardaker wrote: >>>>>> On Mon, 28 Sep 2009 09:42:23 -0700, Andy Bierman said: > > AB> The NETCONF WG decided locking should be optional-to-use, > AB> so your suggestion won't work. > > I certainly understand that view point. But does that mean that no > future feature can depend on or require it to be used? Though in terms > of commit/rollback, it's not exactly a "future" feature. > > AB> I am not going to worry too much about GIGO. > AB> The standard doesn't have any access control at all, > AB> so every server can do what they want. > > Designing a protocol without worrying about access control, whether it > exists at the moment or not, will certainly insert protocol operations > that turn out to be safe when access control is eventually applied to > the problem. I fail to see how this is a safe attitude to take. > > AB> SNMP never had any locking at all, and that > AB> hasn't seemed to cause many problems, or it would have > AB> been forced to add locking at some point. > > SNMP was a much more simple protocol that didn't have commit and > rollback either. If it did, similar issues may have resulted. SNMP > didn't have notions of global config that you could copy around. It > never had to worry about the fact that different users might need to > issue copy commands to move entire config sets around that they may not > even have access rights to modify let alone view. > > It would certainly be easier if you simply declared that netconf was > never to have any sort of access control and was to be treated as a > root-only protocol, but no one has ever tried to declare that and in > fact many people have hinted (yourself included) that access control is > an eventual goal. > > AB> Locks are like traffic lights. If you ignore them, > AB> you rely on random events to prevent collisions. > > Which is why laws exist saying you can't do that. Somehow, though, in > NETCONF you're fine with traffic lights being optional and fine with > them being merely advisory. > > AB> IMO, the standard should not waste a lot of effort describing how > AB> all servers must clean up the wreckage of bad database usage. > > The issue, to me, isn't wreckage of bad data. It's how such oddities of > the protocol can be used by nefarious people to achieve goals beyond > their assigned capabilities. > > If you truly believe that netconf shouldn't have access control, then > you should write a draft that defines authentication = authorization and > see if it's accepted. Maybe it'd be accepted as the best path forward > since it would certainly remove a lot of the issues that come up. At a > cost of course. > I personally tried several times to get the NETCONF WG to work on access control. It has always been a very low priority. There isn't any standard data to configure yet, so a standard way to partition access to the data that doesn't exist yet is not going to be a high priority. Andy From andy@netconfcentral.com Tue Sep 29 08:57: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 3B09528B56A for ; Tue, 29 Sep 2009 08:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.375, 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 rvRSFRdfb1Be for ; Tue, 29 Sep 2009 08:57:07 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 86E623A69B2 for ; Tue, 29 Sep 2009 08:57:07 -0700 (PDT) Received: (qmail 8190 invoked from network); 29 Sep 2009 15:58:26 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 29 Sep 2009 08:58:26 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: wmcd4owVM1mts6HskeCRAhS1nKSBrdD6Es7eytZZ4nkVsYfIcL45rEBK18ADaiQFD6SW4WloiXYeOhLApD6NGyExF6C5c7zHJUsnGt2XznHTYcWw_0CA2imZLRE8YGvVXH4n8klKl8KEI0EqBjWP__HW6yBL.gY5uJ6qGiKUmBhtSNm8hoBZkWq.9Oiu5IJxHTPhpNg52kC4Pyr.5BrZhSfmG5vESFgfpp4lV.JGJ4IA6qOB X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC22E68.6080604@netconfcentral.com> Date: Tue, 29 Sep 2009 08:57:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Wes Hardaker References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> <4AC0E76F.2040806@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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, 29 Sep 2009 15:57:08 -0000 Wes Hardaker wrote: >>>>>> On Mon, 28 Sep 2009 09:42:23 -0700, Andy Bierman said: ... > SNMP was a much more simple protocol that didn't have commit and > rollback either. If it did, similar issues may have resulted. SNMP > didn't have notions of global config that you could copy around. It > never had to worry about the fact that different users might need to > issue copy commands to move entire config sets around that they may not > even have access rights to modify let alone view. > SNMP has the same sort of database validation as NETCONF/YANG, except it isn't really formalized. SNMP has VACM, which is optional-to-use, and was not added to SNMP until well after the protocol was in use with some standard content. We are supposedly in the NETCONF access control requirements gathering phase right now. There are some proprietary ACMs, and maybe more along the way. This should help lead to better understanding of the requirements. There may be renewed interest in a standard ACM after YANG is published. I prefer to see some core data structures to manage first (or concurrently) such as interfaces and system groups. > It would certainly be easier if you simply declared that netconf was > never to have any sort of access control and was to be treated as a > root-only protocol, but no one has ever tried to declare that and in > fact many people have hinted (yourself included) that access control is > an eventual goal. > We didn't do that for SNMP in the early days of SNMP. First the WG has to agree on the requirements, and that isn't going to happen right away. Andy From bertietf@bwijnen.net Wed Sep 30 00:11: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 A2FDC3A6870 for ; Wed, 30 Sep 2009 00:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.684 X-Spam-Level: X-Spam-Status: No, score=-4.684 tagged_above=-999 required=5 tests=[AWL=-2.085, 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 1OrS+hhOFqcN for ; Wed, 30 Sep 2009 00:11:35 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 5D9593A67D8 for ; Wed, 30 Sep 2009 00:11:34 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MstMn-0003oS-AY; Wed, 30 Sep 2009 09:12:54 +0200 Received: from guest-23.ripe.net (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 462FF2F583; Wed, 30 Sep 2009 09:12:49 +0200 (CEST) Message-ID: <4AC304F2.2080607@bwijnen.net> Date: Wed, 30 Sep 2009 09:12:50 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Andy Bierman References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> <4AC0E76F.2040806@netconfcentral.com> <4AC22E68.6080604@netconfcentral.com> In-Reply-To: <4AC22E68.6080604@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd45f8504dda52ef7b8f1fb80b069e692c8 Cc: netconf@ietf.org Subject: [Netconf] Access Control [was: Re: 2 more confirmed-commit details] 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, 30 Sep 2009 07:11:36 -0000 I believe the below discussion has turned into the topic of Access Control. It would be best if we all try to make sure that emai subject lines cover the content of the email. That will make it easier if we need to go through email threads later. Thanks, Bert Andy Bierman wrote: > Wes Hardaker wrote: > >>>>>>> On Mon, 28 Sep 2009 09:42:23 -0700, Andy Bierman said: >>>>>>> > ... > > >> SNMP was a much more simple protocol that didn't have commit and >> rollback either. If it did, similar issues may have resulted. SNMP >> didn't have notions of global config that you could copy around. It >> never had to worry about the fact that different users might need to >> issue copy commands to move entire config sets around that they may not >> even have access rights to modify let alone view. >> >> > > > SNMP has the same sort of database validation as NETCONF/YANG, > except it isn't really formalized. > > SNMP has VACM, which is optional-to-use, and was not added > to SNMP until well after the protocol was in use with > some standard content. > > We are supposedly in the NETCONF access control requirements > gathering phase right now. There are some proprietary > ACMs, and maybe more along the way. This should help > lead to better understanding of the requirements. > > There may be renewed interest in a standard ACM after > YANG is published. I prefer to see some core data structures > to manage first (or concurrently) such as interfaces and system > groups. > > > >> It would certainly be easier if you simply declared that netconf was >> never to have any sort of access control and was to be treated as a >> root-only protocol, but no one has ever tried to declare that and in >> fact many people have hinted (yourself included) that access control is >> an eventual goal. >> >> > > We didn't do that for SNMP in the early days of SNMP. > First the WG has to agree on the requirements, > and that isn't going to happen right away. > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > From wjhns1@hardakers.net Wed Sep 30 09:37: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 685903A6914 for ; Wed, 30 Sep 2009 09:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlBeFZRkhnWk for ; Wed, 30 Sep 2009 09:37:42 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 482713A659B for ; Wed, 30 Sep 2009 09:37:42 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 324B9983A6; Wed, 30 Sep 2009 09:39:05 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Organization: Sparta References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> <4AC0E76F.2040806@netconfcentral.com> <4AC22E68.6080604@netconfcentral.com> Date: Wed, 30 Sep 2009 09:39:05 -0700 In-Reply-To: <4AC22E68.6080604@netconfcentral.com> (Andy Bierman's message of "Tue, 29 Sep 2009 08:57:28 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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, 30 Sep 2009 16:37:43 -0000 >>>>> On Tue, 29 Sep 2009 08:57:28 -0700, Andy Bierman said: AB> SNMP has the same sort of database validation as NETCONF/YANG, AB> except it isn't really formalized. I disagree, they're quite different. But I'm not sure it's relevant. AB> There may be renewed interest in a standard ACM after AB> YANG is published. I prefer to see some core data structures AB> to manage first (or concurrently) such as interfaces and system AB> groups. Getting back to the confirmed-commit issue (Thanks Bert), my point wasn't to argue about access control and how it might work or whether it'll exist. My point was it seems like you're designing protocol features while simultaneously saying "we don't care how this operation works under multi-role models with different access, because there is no access control so we don't have to care". That sort of attitude will certainly end up developing protocol operations that will either fail to work when proper access control is in place, or worse, will prevent an access control method to developed. Consider: A: start confirmed commit A: edit A1 in candidate B: edit B1 in candidate A: kills-own-session B: edit B2 in candidate B: commit Previously you stated: AB> One approach is to say that the server (superuser) is AB> running the rollback and discard-changes, so it always wins, AB> and therefore the rollback wins over the new edits. This is the statement that I don't think is safe. If you want to just say "we don't care about access control because there isn't any" then at some point you'll have to care (maybe?), and I wouldn't be surprised if some of the existing commands will be incompatible with the desired access control because no one thought about them at the same time. -- Wes Hardaker Cobham Analytic Solutions From andy@netconfcentral.com Wed Sep 30 10: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 491E73A6895 for ; Wed, 30 Sep 2009 10:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.242, 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 NZPFCSCHM0Na for ; Wed, 30 Sep 2009 10:10:29 -0700 (PDT) Received: from n13a.bullet.mail.mud.yahoo.com (n13a.bullet.mail.mud.yahoo.com [68.142.207.51]) by core3.amsl.com (Postfix) with SMTP id 4DF963A6822 for ; Wed, 30 Sep 2009 10:10:29 -0700 (PDT) Received: from [68.142.200.225] by n13.bullet.mail.mud.yahoo.com with NNFMP; 30 Sep 2009 17:11:52 -0000 Received: from [68.142.201.72] by t6.bullet.mud.yahoo.com with NNFMP; 30 Sep 2009 17:11:52 -0000 Received: from [127.0.0.1] by omp424.mail.mud.yahoo.com with NNFMP; 30 Sep 2009 17:11:52 -0000 X-Yahoo-Newman-Id: 823284.18129.bm@omp424.mail.mud.yahoo.com Received: (qmail 78064 invoked from network); 30 Sep 2009 17:11:52 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 30 Sep 2009 10:11:52 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: uGf3l2kVM1kgmkcNK0Lfpk1tSgWg2FQmqcbXDD4RiGpXk2w89m9FMvyb6.j3q4962Oq8aE0qSSqSjWT8dGxRPBxWysPZImqNWDvJPdg3K9nXSi4dREWFCdLERO3G0WzDhTUjnR3F85v.I4SLiG8ZY5G9AJGItpxfFJ__pa1Nwz4YuRUJ73QXM_4HuaRCVhR0Z7JOUjJdZFe6anyEY.wRHPN.1rVcOt_S_VCNH6sG4UqmbMDIPqGlXEKw1Ny1gvCgjqtsnorZjlbhAc8DfBC81EDzLef8jZCAWulEGU4bVS0Nr4zjnpN0L4KvZyntoQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC3919C.5090301@netconfcentral.com> Date: Wed, 30 Sep 2009 10:13:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Wes Hardaker References: <4ABFA1EA.1030402@netconfcentral.com> <20090928.090925.25419232.mbj@tail-f.com> <4AC06DCE.3080909@netconfcentral.com> <4AC0E76F.2040806@netconfcentral.com> <4AC22E68.6080604@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 2 more confirmed-commit details 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, 30 Sep 2009 17:10:30 -0000 Wes Hardaker wrote: >>>>>> On Tue, 29 Sep 2009 08:57:28 -0700, Andy Bierman said: > > AB> SNMP has the same sort of database validation as NETCONF/YANG, > AB> except it isn't really formalized. > > I disagree, they're quite different. But I'm not sure it's relevant. > > AB> There may be renewed interest in a standard ACM after > AB> YANG is published. I prefer to see some core data structures > AB> to manage first (or concurrently) such as interfaces and system > AB> groups. > > Getting back to the confirmed-commit issue (Thanks Bert), my point > wasn't to argue about access control and how it might work or whether > it'll exist. My point was it seems like you're designing protocol > features while simultaneously saying "we don't care how this operation > works under multi-role models with different access, because there is no > access control so we don't have to care". That sort of attitude will > certainly end up developing protocol operations that will either fail to > work when proper access control is in place, or worse, will prevent an > access control method to developed. > > Consider: > > A: start confirmed commit > A: edit A1 in candidate > B: edit B1 in candidate > A: kills-own-session > B: edit B2 in candidate > B: commit > big deal. we can all come up with 1000 different ways that the global candidate or running databases can be edited concurrently with bad or unintended results. Confirmed-commit is kind of a corner-case. The global database is shared. If you don't want to share, use locking. > Previously you stated: > > AB> One approach is to say that the server (superuser) is > AB> running the rollback and discard-changes, so it always wins, > AB> and therefore the rollback wins over the new edits. > > This is the statement that I don't think is safe. If you want to just > say "we don't care about access control because there isn't any" then at > some point you'll have to care (maybe?), and I wouldn't be surprised if > some of the existing commands will be incompatible with the desired > access control because no one thought about them at the same time. > I should be more clear. I am using access control, and trying to design a workable system. The standards documents provide part of the solution, but not all of it. That is rather common. It is not my opinion that access control should be optional, let alone ignored by the standard. But I sure don't want something as over-engineered and awful as VACM, so proprietary ACMs are OK for now. Let people prove they know how to manage NETCONF content access control with complete, yet simple solutions. The WG should start with working solutions, not from scratch, and finish in 1 year, not 3 years. By 'we' in 'we don't have to worry about robust protocol operations in the presence of an ACM', I mean the IETF. I agree with you that this is kind of clueless, but the WG consensus has been rather consistent on this point. Look at all the work items that have been chosen instead of an ACM, and you get the impression that this aspect of security is just not relevant at this time. I agree with Phil only because we need standard content before anything else. Standardizing an ACM now would be based entirely on experience with proprietary data models. This may not completely reflect how standard YANG modules are designed. Let's see if any interoperability can be achieved on some core system content first. Andy From mbj@tail-f.com Wed Sep 30 23:34: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 8F6AD28C0F2 for ; Wed, 30 Sep 2009 23:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=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 JUAk9pzL25em for ; Wed, 30 Sep 2009 23:34:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B99CF28B797 for ; Wed, 30 Sep 2009 23:34:54 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id ABD2576C5F4; Thu, 1 Oct 2009 08:36:17 +0200 (CEST) Date: Thu, 01 Oct 2009 08:36:17 +0200 (CEST) Message-Id: <20091001.083617.169773375.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AC0ED35.3070404@netconfcentral.com> References: <4AC0ED35.3070404@netconfcentral.com> X-Mailer: Mew version 6.0.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] comments on monitoring-08 draft 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, 01 Oct 2009 06:34:55 -0000 Andy Bierman wrote: > Hi, > > I noticed that the 'transport' identity was replaced > with a 'session-type' identity, and now the > /sessions/session/transport leaf > has been changed to a session-type leaf. Yet no new > standard identities were added, and no semantics were > altered. Right, this was just a name change of the identity. > I object to this gratuitous incompatible change with -07. > It looks like some tweaks to support proprietary data models. I don't understand how changing the name of a data type is a tweak for proprietary data models. The only reason we changed this name was that the old name, 'transport' has too many connotations. In NETCONF, SSH is a transport, but for the purpose of this document we say that netconf-ssh is a session-type. > IMO, the vendor should augment the entry with a different leaf. > I really want to know the transport, not some meaningless > 'session type' that happens to look like a transport type. > > Also, I thought we were going to make the get-schema/input/version > parameter optional, and add a default=YANG to the format > parameter. I agree with you. > Instead the /sessions/session/loginTime was > changed to mandatory. Do you think it should be mandatory false? If so, why? Should any other leaf be mandatory true? /martin From mbj@tail-f.com Wed Sep 30 23:41: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 54C3528C0EA for ; Wed, 30 Sep 2009 23:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.111, 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 wxKyzcCQ0xWg for ; Wed, 30 Sep 2009 23:41:41 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7AE5428B797 for ; Wed, 30 Sep 2009 23:41:40 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5120B76C5F4; Thu, 1 Oct 2009 08:43:05 +0200 (CEST) Date: Thu, 01 Oct 2009 08:43:05 +0200 (CEST) Message-Id: <20091001.084305.213686165.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090928190418.GB23637@elstar.local> References: <085091CB2CA14E4B8B163FFC37C84E9D1A784EC0@zcarhxm0.corp.nortel.com> <20090928190418.GB23637@elstar.local> X-Mailer: Mew version 6.0.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] Comments on draft-ietf-netconf-monitoring-08 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, 01 Oct 2009 06:41:42 -0000 Hi, I will comment on some of your issues, and let Mark reply to the others. Juergen Schoenwaelder wrote: > On Mon, Sep 28, 2009 at 07:05:15PM +0200, Mark Scott wrote: > > > This version addresses action items from IETF75 and mailing list > > comments. Most significant is the decision to adopt YANG as > > normative for this draft. > > I still do not like the capitalized identifiers. +1 > Furthermore, we > should import relevant types from ietf-netconf (SessionId can clearly > be imported). The NETCONFDatastoreType should probably be provided by > ietf-netconf (after renaming). I agree in principle, but that would mean that this document will wait not only for YANG, but also for rfc4741bis. Do we want to do that? > I am wondering why you use zero-based-counter32 and not just > counter32. Do we worry about the fact that this might rollover and > become ambiguous? This way you can easily see if e.g. any errors has happend in a session. You know that it starts from 0 when the session starts. > I think all definitions should have proper descriptions. Not all have > them. > > What is the reason to define groupings inline? Do you prefer to export all groupings? /martin From j.schoenwaelder@jacobs-university.de Wed Sep 30 23:54:06 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 B1C323A67A1 for ; Wed, 30 Sep 2009 23:54:06 -0700 (PDT) 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=[AWL=0.139, 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 tkkfFNoGIgQk for ; Wed, 30 Sep 2009 23:54:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BF5873A67B6 for ; Wed, 30 Sep 2009 23:54:05 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19A28C0011; Thu, 1 Oct 2009 08:55:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ICcc8GOvmTnd; Thu, 1 Oct 2009 08:55:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 29C8BC0005; Thu, 1 Oct 2009 08:55:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 16EE7D0A7BB; Thu, 1 Oct 2009 08:55:28 +0200 (CEST) Date: Thu, 1 Oct 2009 08:55:28 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091001065528.GB29299@elstar.local> Mail-Followup-To: Martin Bjorklund , "markscot@nortel.com" , "netconf@ietf.org" References: <085091CB2CA14E4B8B163FFC37C84E9D1A784EC0@zcarhxm0.corp.nortel.com> <20090928190418.GB23637@elstar.local> <20091001.084305.213686165.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091001.084305.213686165.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-08 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: Thu, 01 Oct 2009 06:54:06 -0000 On Thu, Oct 01, 2009 at 08:43:05AM +0200, Martin Bjorklund wrote: > > I am wondering why you use zero-based-counter32 and not just > > counter32. Do we worry about the fact that this might rollover and > > become ambiguous? > > This way you can easily see if e.g. any errors has happend in a > session. You know that it starts from 0 when the session starts. This is true only under the assumption that the counter did never roll over in a session. Is this assumption reasonable to make for the counters? > > What is the reason to define groupings inline? > > Do you prefer to export all groupings? So you defined groupings inline so they can't be used elsewhere? I am just trying to understand; personally I have no problem with exporting groupings by default since you never know what a vendor extension wants to reuse. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103