From nobody Mon May 4 14:19:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B881B2C54 for ; Mon, 4 May 2015 14:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx7kVzO8zoA2 for ; Mon, 4 May 2015 14:19:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4127F1A88C3 for ; Mon, 4 May 2015 14:19:32 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.154.19; Mon, 4 May 2015 21:19:10 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.63]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.63]) with mapi id 15.01.0148.019; Mon, 4 May 2015 21:19:10 +0000 From: Kent Watsen To: Andy Bierman , Netconf Thread-Topic: [Netconf] RESTCONF #21: operation input output encoding Thread-Index: AQHQgueu6iiAnwU390KmolvRbH40WJ1sFw4A Date: Mon, 4 May 2015 21:19:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 05669A7924 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(102836002)(86362001)(2950100001)(2900100001)(92566002)(46102003)(19580395003)(15975445007)(99286002)(66066001)(36756003)(83506001)(5001960100002)(107886002)(122556002)(76176999)(50986999)(40100003)(62966003)(54356999)(77156002)(106116001)(5001770100001)(2656002)(87936001)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <5A59E4FDB2C57D41A1E1D9E2292D490A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2015 21:19:10.2403 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Subject: Re: [Netconf] RESTCONF #21: operation input output encoding X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 21:19:34 -0000 >A new RESTCONF issue has been added: > >https://github.com/netconf-wg/restconf/issues/21 > >This issue proposes to change the encoding of operation >input and output parameters: > > - change "input" tp rpc name > - change "output" to rpc-name > >If there are no objections by May 7, then this >change will be added to the next draft (-05). Hi Andy,=20 I don't agree to this, at least not without discussion. We (Martin, you, and myself) discussed this (and action statements) privately on Mar 31 and again on Apr 9/10 - a total of 26 messages, where we landed on sticking with the input/output top-level elements - what's changed? Given that the current encoding has been with us since the beginning, changing it now needs to be done with care. Personally, I find the input/output elements more useful, as already the URL encodes the name of the RPC - having the RPC's name again in the body of the message seems redundant, whereas input/output provides context. Additionally, keep in mind that, with action statements, there can be many actions with the same name. For this reason, it's never possible to process an input or output message body without context (e.g., pyang would have to have a parameter indicated *which* action statement to assume). Is your motivation for this change to enable contextless processing? Thanks, Kent From nobody Mon May 4 14:35:02 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657A21B2C87 for ; Mon, 4 May 2015 14:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK8tPLJ2grf6 for ; Mon, 4 May 2015 14:34:58 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2685F1B2C85 for ; Mon, 4 May 2015 14:34:58 -0700 (PDT) Received: by lagv1 with SMTP id v1so113799375lag.3 for ; Mon, 04 May 2015 14:34:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SgPKIzpoZYu4TBGynBVJVEU2qqrUxjYWMVwpvNUQvtw=; b=cq+qOY2isxUfjVcOhNgotg6xpjw+R2wJ0Ql2Bvn8JwXjGxFHz3vkQjBptfsTCBJvyV rmVmWhNqGYwpgoMrDolhgGlz4aFI08FX8sM9T1lQnbVH/ducKLnd++m8L3qH8Fzyj7os V27uOwhLM0mNgt4xtrcIjpYmQUdcKGnSVYy6oGwe6888ypHGIJDea5HIbkL7xqPjlWPi gv6pfu+vz+kJv/KhOR08Q1ljtun7AA26EfEb+sAP6KCpPnoPn8ZzT2KsxJqceEyCN7nD 7mADNnJjOYI1Pn8BqrvUv7VZbT4xR8sW1Y3xSKsXMm+/lEiDjp9JLYF+nmp6brncNxNx wLJA== X-Gm-Message-State: ALoCoQmiEq8ifc+o5Klohrp4zbwgY/aZYcswi45o1ZQcjoJOCyfYmyDpRxIb3/9n+6mjHNnoD3pf MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr484159lab.82.1430775296361; Mon, 04 May 2015 14:34:56 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 4 May 2015 14:34:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 May 2015 14:34:56 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF #21: operation input output encoding X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 21:35:00 -0000 On Mon, May 4, 2015 at 2:19 PM, Kent Watsen wrote: > >>A new RESTCONF issue has been added: >> >>https://github.com/netconf-wg/restconf/issues/21 >> >>This issue proposes to change the encoding of operation >>input and output parameters: >> >> - change "input" tp rpc name >> - change "output" to rpc-name >> >>If there are no objections by May 7, then this >>change will be added to the next draft (-05). > > > Hi Andy, > > I don't agree to this, at least not without discussion. > > We (Martin, you, and myself) discussed this (and action statements) > privately on Mar 31 and again on Apr 9/10 - a total of 26 messages, where > we landed on sticking with the input/output top-level elements - what's > changed? Given that the current encoding has been with us since the > beginning, changing it now needs to be done with care. > > Personally, I find the input/output elements more useful, as already the > URL encodes the name of the RPC - having the RPC's name again in the body > of the message seems redundant, whereas input/output provides context. > Additionally, keep in mind that, with action statements, there can be many > actions with the same name. For this reason, it's never possible to > process an input or output message body without context (e.g., pyang would > have to have a parameter indicated *which* action statement to assume). > Is your motivation for this change to enable contextless processing? > The problem is that all RPCs from the same module look the same and there is no way to associate the data with the operation other than knowing the request URI that goes with the data .... ... OR ... ... The is what we do in NETCONF. RESTCONF is supposed to be consistent with NETCONF unless there is a good reason to do otherwise. > Thanks, > Kent Andy > > > > > From nobody Tue May 5 20:06:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDF41B2A50 for ; Tue, 5 May 2015 20:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh1ptXNBdphd for ; Tue, 5 May 2015 20:05:58 -0700 (PDT) Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D719B1B2A1E for ; Tue, 5 May 2015 20:05:57 -0700 (PDT) Received: from [192.168.2.34] ([73.8.162.228]) by p3plsmtpa12-10.prod.phx3.secureserver.net with id QT5w1q0064vySjM01T5wTk; Tue, 05 May 2015 20:05:57 -0700 Message-ID: <55498514.2050003@seguesoft.com> Date: Tue, 05 May 2015 22:05:56 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: netconf@ietf.org References: <20150410.082116.663742183631558687.mbj@tail-f.com> In-Reply-To: <20150410.082116.663742183631558687.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] subtree filter normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 03:05:59 -0000 Hi On 4/10/2015 1:21 AM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> I'm trying to rewrite some NETCONF code, and I cannot >> tell if RFC 6241 allows for subtree filters to be normalized. >> It is not clear how certain usage should be processed. >> >> This text in 6.1, para 1 seems to suggest the filter does not >> need to follow a schema. >> >> The server does not need to utilize any data-model- >> specific semantics during processing, allowing for simple and >> centralized implementation strategies. >> >> >> I am not convinced NETCONF is correct here >> (and I wrote a lot of this subtree text ;-) >> IMO the server MUST return schema-valid content >> for YANG modules it advertises, >> and that requires the filter to be interpreted >> and the response content normalized. > This would indeed have been better! But that's not what the spec > says... > > >> F0 is the well-behaved example on pg 25: >> >> F0: >> >> >> >> >> fred >> >> >> >> >> >> The RFC does not say if the 'name' select node can be repeated, >> as in F1: >> >> F1: >> >> >> >> >> fred >> barney >> >> >> >> >> >> 6.2.5, bullet 2 says these are ANDed together, so >> filter F1 would not match anything. IMO this should only >> apply to different select leafs. Duplicate select leafs >> should be ORed together. This will help normalization. > I think the current behavior is correct. If you want to get both fred > and barney you have to do: > > > fred > > > barney > > > I don't think there is any reason for a special case when the select > node is duplicated. It can actually be confusing. Assuming the list > has two keys, what would this mean: > > > martin > andy > bjorklund > bierman > > >> F2: >> >> >> >> >> fred >> >> >> fred >> >> >> >> >> >> Is F2 allowed? (container user repeated) >> Is the server required to collapse the entries for return >> so the rpc-reply is schema-valid? > In this case the natural reply is schema-valid: > > > > > fred > ... > > > fred > ... > > > But RFC6241 6.1 also says: ... Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data. Shouldn't the example F2 be considered as "a request contains multiple filter subtree expressions that select the same data" and hence the duplicates need to be suppressed? Thanks --Xiang From nobody Tue May 5 20:21:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6A21A89B4 for ; Tue, 5 May 2015 20:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22phSgIPB7Vu for ; Tue, 5 May 2015 20:21:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8B81ACDD8 for ; Tue, 5 May 2015 20:21:50 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so143189332lbb.3 for ; Tue, 05 May 2015 20:21:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=48L5DaZZN/ViwHJ8gkQ0uvK2CKu0rVisJh3sbq5Ql+E=; b=CdGwCtR5EQ2FrAbbkAZixWYWS4VB32fY62LCTd1jP8kBzYmf+nZTp6oZh1Wi7EKL4v Tgrqcv+an/Q4dxz0axPcrnX5PwI9F9b1OJHiVkwkIGIxv5A7gOfivRtHrGWRsDUi0htK cX7qWcMFwwOlVel3YSy54BKrfuWwSMS0RBwFTFUWoqB78ySldlJrC+eCtPTvnsQO3lXY cIx2G8+C7xXC/GHBjVz1BTLEQoNmvbd2DYlJcHNHwdbrqYK4uRXJnvK8DT9zBuNcJa1V HFX5A85M2gaXXKErPdrdhhbui0Oj2ipM2OaThrrjMFiitWiXb+Cs2gf7wqUXLe3wU3he DiSQ== X-Gm-Message-State: ALoCoQlBB8R7EGpxYJCR2mBFArRuYFt8eH4Qyw/g4iIFEU3HTu8+8JBNA6hb8tmTKdRuM9bj1XvS MIME-Version: 1.0 X-Received: by 10.152.204.7 with SMTP id ku7mr4690294lac.38.1430882508484; Tue, 05 May 2015 20:21:48 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 5 May 2015 20:21:48 -0700 (PDT) In-Reply-To: <55498514.2050003@seguesoft.com> References: <20150410.082116.663742183631558687.mbj@tail-f.com> <55498514.2050003@seguesoft.com> Date: Tue, 5 May 2015 20:21:48 -0700 Message-ID: From: Andy Bierman To: Xiang Li Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] subtree filter normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 03:21:52 -0000 On Tue, May 5, 2015 at 8:05 PM, Xiang Li wrote: > Hi > > On 4/10/2015 1:21 AM, Martin Bjorklund wrote: >> >> Hi, >> >> Andy Bierman wrote: >>> >>> Hi, >>> >>> I'm trying to rewrite some NETCONF code, and I cannot >>> tell if RFC 6241 allows for subtree filters to be normalized. >>> It is not clear how certain usage should be processed. >>> >>> This text in 6.1, para 1 seems to suggest the filter does not >>> need to follow a schema. >>> >>> The server does not need to utilize any data-model- >>> specific semantics during processing, allowing for simple and >>> centralized implementation strategies. >>> >>> >>> I am not convinced NETCONF is correct here >>> (and I wrote a lot of this subtree text ;-) >>> IMO the server MUST return schema-valid content >>> for YANG modules it advertises, >>> and that requires the filter to be interpreted >>> and the response content normalized. >> >> This would indeed have been better! But that's not what the spec >> says... >> >> >>> F0 is the well-behaved example on pg 25: >>> >>> F0: >>> >>> >>> >>> >>> fred >>> >>> >>> >>> >>> >>> The RFC does not say if the 'name' select node can be repeated, >>> as in F1: >>> >>> F1: >>> >>> >>> >>> >>> fred >>> barney >>> >>> >>> >>> >>> >>> 6.2.5, bullet 2 says these are ANDed together, so >>> filter F1 would not match anything. IMO this should only >>> apply to different select leafs. Duplicate select leafs >>> should be ORed together. This will help normalization. >> >> I think the current behavior is correct. If you want to get both fred >> and barney you have to do: >> >> >> fred >> >> >> barney >> >> >> I don't think there is any reason for a special case when the select >> node is duplicated. It can actually be confusing. Assuming the list >> has two keys, what would this mean: >> >> >> martin >> andy >> bjorklund >> bierman >> >> >>> F2: >>> >>> >>> >>> >>> fred >>> >>> >>> fred >>> >>> >>> >>> >>> >>> Is F2 allowed? (container user repeated) >>> Is the server required to collapse the entries for return >>> so the rpc-reply is schema-valid? >> >> In this case the natural reply is schema-valid: >> >> >> >> >> fred >> ... >> >> >> fred >> ... >> >> >> > > > > But RFC6241 6.1 also says: > > ... > Specific data instances are not duplicated in the response in the event > that > the request contains multiple filter subtree expressions that select > the same data. > > > > Shouldn't the example F2 be considered as "a request contains multiple > filter subtree expressions that select the same data" and hence the > duplicates need to be suppressed? > Perhaps. I implemented the code a bit more literally. Duplicate sibling selection nodes are eliminated but not duplicate subtrees that contain content-match nodes. Martin pointed out this text that says a schema is not needed, as an indication that the data returned in the element did not need to be schema-valid The server does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. Maybe the server should be able to detect the duplicate subtrees in F2, even without a schema, but maybe if the client asks the same question 3 times, then just answer it 3 times. > Thanks > --Xiang Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed May 6 00:13:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75DA1A8761 for ; Wed, 6 May 2015 00:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8fu-82OpvpG for ; Wed, 6 May 2015 00:13:47 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 633561A86EB for ; Wed, 6 May 2015 00:13:47 -0700 (PDT) Received: from [10.61.160.165] (unknown [173.38.220.53]) by mail.tail-f.com (Postfix) with ESMTPSA id B898D1AE06C0; Wed, 6 May 2015 09:13:45 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2EECAAAE-0100-4231-9ABB-D164D9475A3A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Stefan Wallin In-Reply-To: <1F9CBA2C-D328-4DAF-9194-D2AB58013DC0@cisco.com> Date: Wed, 6 May 2015 09:13:42 +0200 Message-Id: References: <1F9CBA2C-D328-4DAF-9194-D2AB58013DC0@cisco.com> To: Stefan Vallin X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Alarms? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 07:13:49 -0000 --Apple-Mail=_2EECAAAE-0100-4231-9ABB-D164D9475A3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! See: http://tools.ietf.org/html/draft-vallin-alarm-yang-module-00 >=20 > =E2=80=94 > Hi, >=20 > Is there any definition for alarms carried by NETCONF notifications? >=20 > I see some classic X.733 definitions in = https://tools.ietf.org/html/draft-ietf-netconf-notification-00#appendix-A = but I don't see anything in subsequent RFCs or = https://github.com/YangModels. >=20 > What are people using for alarms today? >=20 > Regards, > Andrew --Apple-Mail=_2EECAAAE-0100-4231-9ABB-D164D9475A3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


= --Apple-Mail=_2EECAAAE-0100-4231-9ABB-D164D9475A3A-- From nobody Wed May 6 03:50:31 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24E51A89AD for ; Wed, 6 May 2015 03:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzGjDiXBF_QD for ; Wed, 6 May 2015 03:50:27 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 61D321A88FE for ; Wed, 6 May 2015 03:50:26 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E0D4A1CC045B; Wed, 6 May 2015 12:50:25 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20150410.082116.663742183631558687.mbj@tail-f.com> References: <20150410.082116.663742183631558687.mbj@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 06 May 2015 12:50:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] subtree filter normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 10:50:30 -0000 Martin Bjorklund writes: > Hi, > > Andy Bierman wrote: >> Hi, >> >> I'm trying to rewrite some NETCONF code, and I cannot >> tell if RFC 6241 allows for subtree filters to be normalized. >> It is not clear how certain usage should be processed. >> >> This text in 6.1, para 1 seems to suggest the filter does not >> need to follow a schema. >> >> The server does not need to utilize any data-model- >> specific semantics during processing, allowing for simple and >> centralized implementation strategies. >> >> >> I am not convinced NETCONF is correct here >> (and I wrote a lot of this subtree text ;-) >> IMO the server MUST return schema-valid content >> for YANG modules it advertises, >> and that requires the filter to be interpreted >> and the response content normalized. > > This would indeed have been better! But that's not what the spec > says... > > >> F0 is the well-behaved example on pg 25: >> >> F0: >> >> >> >> >> fred >> >> >> >> >> >> The RFC does not say if the 'name' select node can be repeated, >> as in F1: >> >> F1: >> >> >> >> >> fred >> barney >> >> >> >> >> >> 6.2.5, bullet 2 says these are ANDed together, so >> filter F1 would not match anything. IMO this should only >> apply to different select leafs. Duplicate select leafs >> should be ORed together. This will help normalization. > > I think the current behavior is correct. If you want to get both fred > and barney you have to do: > > > fred > > > barney > > > I don't think there is any reason for a special case when the select > node is duplicated. It can actually be confusing. Assuming the list > has two keys, what would this mean: > > > martin > andy > bjorklund > bierman > > >> F2: >> >> >> >> >> fred >> >> >> fred >> >> >> >> >> >> Is F2 allowed? (container user repeated) >> Is the server required to collapse the entries for return >> so the rpc-reply is schema-valid? > > In this case the natural reply is schema-valid: Is it? If the example is yangified, "name" would most likely be the list key, and they we have duplicate keys in the response. Lada > > > > > fred > ... > > > fred > ... > > > > > >> Same applies to F3 and F4. > > The way the spec is written (data model agnostic), you'd get a reply > that mimics the filter input. The only way for a server to collapse > the s into a single element, is to utilize the fact that > "users" is a container. > >> F3: variant of F2 >> >> >> >> >> fred >> >> >> >> >> fred >> >> >> >> >> >> F4: variant of F2 >> >> >> >> >> fred >> >> >> >> >> >> >> barney >> >> >> >> > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed May 6 19:27:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512911A86EB for ; Wed, 6 May 2015 00:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.166 X-Spam-Level: X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyI9d_FiaGhA for ; Wed, 6 May 2015 00:11:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1009A1A872B for ; Wed, 6 May 2015 00:11:00 -0700 (PDT) Received: from [172.20.10.4] (host-78-78-2-220.mobileonline.telia.com [78.78.2.220]) by mail.tail-f.com (Postfix) with ESMTPSA id D9C341AE06C0; Wed, 6 May 2015 09:10:57 +0200 (CEST) From: "Stefan Vallin (svallin)" Content-Type: multipart/alternative; boundary="Apple-Mail=_8D277C2B-3718-4BDB-AEA1-83EB576EB486" Message-Id: <1F9CBA2C-D328-4DAF-9194-D2AB58013DC0@cisco.com> Date: Wed, 6 May 2015 09:11:06 +0200 To: netconf@ietf.org, stone@openclovis.com Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: X-Mailman-Approved-At: Wed, 06 May 2015 19:27:14 -0700 Subject: Re: [Netconf] Alarms? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 07:11:06 -0000 --Apple-Mail=_8D277C2B-3718-4BDB-AEA1-83EB576EB486 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 See: http://tools.ietf.org/html/draft-vallin-alarm-yang-module-00 = =E2=80=94 Hi, Is there any definition for alarms carried by NETCONF notifications? I see some classic X.733 definitions in = https://tools.ietf.org/html/draft-ietf-netconf-notification-00#appendix-A = but I don't see anything in subsequent RFCs or = https://github.com/YangModels. What are people using for alarms today? Regards, Andrew= --Apple-Mail=_8D277C2B-3718-4BDB-AEA1-83EB576EB486 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 See:

http://tools.ietf.org/html/draft-vallin-alarm-yang-module-00

=E2=80=94
Hi,

Is there any = definition for alarms carried by NETCONF notifications?

I see some classic X.733 definitions in https://tools.ietf.org/html/draft-ietf-netconf-notification-00#= appendix-A but I don't see anything in subsequent RFCs = or https://github.com/YangModels.

What = are people using for alarms today?

Regards,
Andrew
= --Apple-Mail=_8D277C2B-3718-4BDB-AEA1-83EB576EB486-- From nobody Thu May 7 13:08:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6A91A873B for ; Thu, 7 May 2015 13:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPDzDaimKsBZ for ; Thu, 7 May 2015 13:08:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0165A1A0369 for ; Thu, 7 May 2015 13:08:30 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 0B8FAAAE395D3; Thu, 7 May 2015 20:08:24 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t47K8Rsg012471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 16:08:27 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.179]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 7 May 2015 16:08:27 -0400 From: "Sterne, Jason (Jason)" To: Andy Bierman , Xiang Li Thread-Topic: [Netconf] subtree filter normalization Thread-Index: AQHQh6vRlEg48thBWkOpiJpZR2OyIZ1w84cw Date: Thu, 7 May 2015 20:08:26 +0000 Message-ID: References: <20150410.082116.663742183631558687.mbj@tail-f.com> <55498514.2050003@seguesoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: Re: [Netconf] subtree filter normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:08:33 -0000 I'm with Andy on this. I don't think the server should be *required* to fi= lter out the duplicate fred in that example. Jason -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, May 05, 2015 11:22 PM To: Xiang Li Cc: Netconf Subject: Re: [Netconf] subtree filter normalization On Tue, May 5, 2015 at 8:05 PM, Xiang Li wrote: > Hi > > On 4/10/2015 1:21 AM, Martin Bjorklund wrote: >> >> Hi, >> >> Andy Bierman wrote: >>> >>> Hi, >>> >>> I'm trying to rewrite some NETCONF code, and I cannot tell if RFC=20 >>> 6241 allows for subtree filters to be normalized. >>> It is not clear how certain usage should be processed. >>> >>> This text in 6.1, para 1 seems to suggest the filter does not need=20 >>> to follow a schema. >>> >>> The server does not need to utilize any data-model- >>> specific semantics during processing, allowing for simple and >>> centralized implementation strategies. >>> >>> >>> I am not convinced NETCONF is correct here (and I wrote a lot of=20 >>> this subtree text ;-) IMO the server MUST return schema-valid=20 >>> content for YANG modules it advertises, and that requires the filter=20 >>> to be interpreted and the response content normalized. >> >> This would indeed have been better! But that's not what the spec=20 >> says... >> >> >>> F0 is the well-behaved example on pg 25: >>> >>> F0: >>> >>> >>> >>> >>> fred >>> >>> >>> >>> >>> >>> The RFC does not say if the 'name' select node can be repeated, as=20 >>> in F1: >>> >>> F1: >>> >>> >>> >>> >>> fred >>> barney >>> >>> >>> >>> >>> >>> 6.2.5, bullet 2 says these are ANDed together, so filter F1 would=20 >>> not match anything. IMO this should only apply to different select=20 >>> leafs. Duplicate select leafs should be ORed together. This will=20 >>> help normalization. >> >> I think the current behavior is correct. If you want to get both=20 >> fred and barney you have to do: >> >> >> fred >> >> >> barney >> >> >> I don't think there is any reason for a special case when the select=20 >> node is duplicated. It can actually be confusing. Assuming the list=20 >> has two keys, what would this mean: >> >> >> martin >> andy >> bjorklund >> bierman >> >> >>> F2: >>> >>> >>> >>> >>> fred >>> >>> >>> fred >>> >>> >>> >>> >>> >>> Is F2 allowed? (container user repeated) Is the server required to=20 >>> collapse the entries for return so the rpc-reply is schema-valid? >> >> In this case the natural reply is schema-valid: >> >> >> >> >> fred >> ... >> >> >> fred >> ... >> >> >> > > > > But RFC6241 6.1 also says: > > ... > Specific data instances are not duplicated in the response in the=20 > event that > the request contains multiple filter subtree expressions that select > the same data. > > > > Shouldn't the example F2 be considered as "a request contains=20 > multiple filter subtree expressions that select the same data" and=20 > hence the duplicates need to be suppressed? > Perhaps. I implemented the code a bit more literally. Duplicate sibling selection nodes are eliminated but not duplicate subtrees= that contain content-match nodes. Martin pointed out this text that says a schema is not needed, as an indica= tion that the data returned in the element did not need to be schema= -valid The server does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. Maybe the server should be able to detect the duplicate subtrees in F2, eve= n without a schema, but maybe if the client asks the same question 3 times,= then just answer it 3 times. > Thanks > --Xiang Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Thu May 7 13:44:13 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F9E1AD26E; Thu, 7 May 2015 13:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7qYmMtD5DNG; Thu, 7 May 2015 13:44:09 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497151AD289; Thu, 7 May 2015 13:43:53 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so49728782pac.1; Thu, 07 May 2015 13:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=akjOkYjdHma9lcD19dKRgStVTf+Ok0VG5FwZhZlhWvY=; b=sP1Yd/t79twEiyIXfKvgJOpux44SPaEnlOY66a/I23TgcuTRSV01BBQqZvxi6S3JCF VgqtDRncYEIQuM3LkKd8JgU2CZVngB08Xew3m8cF/SEKBQEc+iFEtEuZGO3GddENBPFX CwQt+cfV3y8Pe2qrylZsQQZkUnkmbB1Sv7WbC2qXS9VV0+kQY2Kb3vuH5tE6J6wfIVJr tuMGpFc7pmu2Mdccbd1xe+sWVBxnyQF6ERMA+EurYL6LvEpjsSt8Tm6pwXD2kbr+i1Co /J5fsmpnjF0ORIOLe7CAHrF9r5Xiv8j1VTKTzew54idky1D1vLCRHdO5uPhzAXsbctsh M7RA== X-Received: by 10.68.106.193 with SMTP id gw1mr263224pbb.111.1431031432992; Thu, 07 May 2015 13:43:52 -0700 (PDT) Received: from ?IPv6:2001:420:302:1330:7197:4184:582e:ba8f? ([2001:420:302:1330:7197:4184:582e:ba8f]) by mx.google.com with ESMTPSA id cp10sm3028451pdb.44.2015.05.07.13.43.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 May 2015 13:43:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 7 May 2015 13:43:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <32144132-ACB1-4CB5-A6EC-8CE6515E6318@gmail.com> References: <167E7B4797E08C4DBC40AED09620195943C95C57@TELMBA001BA020.telecomitalia.local> <20150507201450.GB13768@elstar.local> To: "netmod@ietf.org" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netconf Subject: Re: [Netconf] [netmod] YANG Alarm Module X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:44:10 -0000 [Cross-posting it to NETCONF] Stefan, did try to post to netconf, but it got blocked because he was = not subscribed to the mailing list. I agree with Juegen that the topic of what transport mechanism is used = belongs to the NETCONF WG, and is certainly an area of interest to the = WG. [Chair hat off] In trying to address the issue, we need to address the issue of what = happens if there are either no sessions connected to the server or = thousands of them. For the latter, we might have to look at a pub/sub = model to contain where alarms get delivered. Throw in other = notifications and now you are looking at prioritizing event = notifications, as I am sure alarms would like to be treated at a = different priority. p.s. Pardon my multiple attempts to post this message >=20 >>=20 >>> On May 7, 2015, at 1:14 PM, Juergen Schoenwaelder = wrote: >>>=20 >>> On Thu, May 07, 2015 at 08:10:38PM +0000, Sterne, Jason (Jason) = wrote: >>>=20 >>>> Or alternate streaming-type transport options for NETCONF = notifications ? >>>=20 >>> The topic how to transport YANG defined notifications seems to = belongs >>> to the NETCONF WG mailing list and not really to the NETMOD mailing >>> list (although I understand why it started here). >>>=20 >>> /js >>>=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Thu May 7 15:17:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310501B2B49 for ; Thu, 7 May 2015 15:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHwFuCjSyu_E for ; Thu, 7 May 2015 15:17:00 -0700 (PDT) Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA9B1B29AF for ; Thu, 7 May 2015 15:17:00 -0700 (PDT) Received: from [192.168.2.34] ([73.8.162.228]) by p3plsmtpa09-03.prod.phx3.secureserver.net with id RAGy1q00U4vySjM01AGz1l; Thu, 07 May 2015 15:16:59 -0700 Message-ID: <554BE45A.9050703@seguesoft.com> Date: Thu, 07 May 2015 17:16:58 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Andy Bierman References: <20150410.082116.663742183631558687.mbj@tail-f.com> <55498514.2050003@seguesoft.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf Subject: Re: [Netconf] subtree filter normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 22:17:02 -0000 On 5/5/2015 10:21 PM, Andy Bierman wrote: > On Tue, May 5, 2015 at 8:05 PM, Xiang Li wrote: >> Hi >> >> On 4/10/2015 1:21 AM, Martin Bjorklund wrote: >>> Hi, >>> >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> I'm trying to rewrite some NETCONF code, and I cannot >>>> tell if RFC 6241 allows for subtree filters to be normalized. >>>> It is not clear how certain usage should be processed. >>>> >>>> This text in 6.1, para 1 seems to suggest the filter does not >>>> need to follow a schema. >>>> >>>> The server does not need to utilize any data-model- >>>> specific semantics during processing, allowing for simple and >>>> centralized implementation strategies. >>>> >>>> >>>> I am not convinced NETCONF is correct here >>>> (and I wrote a lot of this subtree text ;-) >>>> IMO the server MUST return schema-valid content >>>> for YANG modules it advertises, >>>> and that requires the filter to be interpreted >>>> and the response content normalized. >>> This would indeed have been better! But that's not what the spec >>> says... >>> >>> >>>> F0 is the well-behaved example on pg 25: >>>> >>>> F0: >>>> >>>> >>>> >>>> >>>> fred >>>> >>>> >>>> >>>> >>>> >>>> The RFC does not say if the 'name' select node can be repeated, >>>> as in F1: >>>> >>>> F1: >>>> >>>> >>>> >>>> >>>> fred >>>> barney >>>> >>>> >>>> >>>> >>>> >>>> 6.2.5, bullet 2 says these are ANDed together, so >>>> filter F1 would not match anything. IMO this should only >>>> apply to different select leafs. Duplicate select leafs >>>> should be ORed together. This will help normalization. >>> I think the current behavior is correct. If you want to get both fred >>> and barney you have to do: >>> >>> >>> fred >>> >>> >>> barney >>> >>> >>> I don't think there is any reason for a special case when the select >>> node is duplicated. It can actually be confusing. Assuming the list >>> has two keys, what would this mean: >>> >>> >>> martin >>> andy >>> bjorklund >>> bierman >>> >>> >>>> F2: >>>> >>>> >>>> >>>> >>>> fred >>>> >>>> >>>> fred >>>> >>>> >>>> >>>> >>>> >>>> Is F2 allowed? (container user repeated) >>>> Is the server required to collapse the entries for return >>>> so the rpc-reply is schema-valid? >>> In this case the natural reply is schema-valid: >>> >>> >>> >>> >>> fred >>> ... >>> >>> >>> fred >>> ... >>> >>> >>> >> >> >> But RFC6241 6.1 also says: >> >> ... >> Specific data instances are not duplicated in the response in the event >> that >> the request contains multiple filter subtree expressions that select >> the same data. >> >> >> >> Shouldn't the example F2 be considered as "a request contains multiple >> filter subtree expressions that select the same data" and hence the >> duplicates need to be suppressed? >> > Perhaps. > I implemented the code a bit more literally. > Duplicate sibling selection nodes are eliminated but not duplicate > subtrees that contain content-match nodes. So here "Specific data instances are not duplicated in the response" literally means "duplicated sibling instances"? I think that's fine and it is what I assumed after reading this paragraph. But then is it an error if the server suppresses the duplicated subtrees in the response, because the server did not provide exactly what were asked? Or it is an implementation specific choice? Thanks, -Xiang From nobody Sun May 10 13:40:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05DD1A9238 for ; Sun, 10 May 2015 13:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI45O0ITLmFN for ; Sun, 10 May 2015 13:40:19 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2AF1A8AAD for ; Sun, 10 May 2015 13:40:19 -0700 (PDT) Received: from wonder.chopps.org.chopps.org (c-68-61-203-90.hsd1.mi.comcast.net [68.61.203.90]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 387666003F; Sun, 10 May 2015 20:40:18 +0000 (UTC) References: <20150410.082116.663742183631558687.mbj@tail-f.com> <55498514.2050003@seguesoft.com> From: Christian Hopps To: "Sterne\, Jason \(Jason\)" In-reply-to: Date: Sun, 10 May 2015 16:40:16 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Netconf Subject: Re: [Netconf] subtree filter normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 20:40:21 -0000 I agree as well. In particular I agree with the latter half of: > Maybe the server should be able to detect the duplicate subtrees in > F2, even without a schema, but maybe if the client asks the same > question 3 times, then just answer it 3 times. Thanks, Chris. Sterne, Jason (Jason) writes: > I'm with Andy on this. I don't think the server should be *required* to filter out the duplicate fred in that example. > > Jason > > -----Original Message----- > On Tue, May 5, 2015 at 8:05 PM, Xiang Li wrote: >>> Andy Bierman wrote: >>>> F2: >>>> >>>> >>>> >>>> >>>> fred >>>> >>>> >>>> fred >>>> >>>> >>>> >>>> >>>> >>>> Is F2 allowed? (container user repeated) Is the server required to >>>> collapse the entries for return so the rpc-reply is schema-valid? >>> >>> In this case the natural reply is schema-valid: >>> >>> >>> >>> >>> fred >>> ... >>> >>> >>> fred >>> ... >>> >>> >>> >> >> Shouldn't the example F2 be considered as "a request contains >> multiple filter subtree expressions that select the same data" and >> hence the duplicates need to be suppressed? >> > > Perhaps. > I implemented the code a bit more literally. > Duplicate sibling selection nodes are eliminated but not duplicate subtrees that contain content-match nodes. > > Martin pointed out this text that says a schema is not needed, as an indication that the data returned in the element did not need to be schema-valid > > The server does not need to utilize any data-model- > specific semantics during processing, allowing for simple and > centralized implementation strategies. > > Maybe the server should be able to detect the duplicate subtrees in F2, even without a schema, but maybe if the client asks the same question 3 times, then just answer it 3 times. > > >> Thanks >> --Xiang > > Andy From nobody Tue May 12 19:38:31 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A813F1A908E; Tue, 12 May 2015 19:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX1llOaqTJnY; Tue, 12 May 2015 19:38:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3181A9080; Tue, 12 May 2015 19:38:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513023827.20745.19141.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 19:38:27 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 02:38:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-05.txt Pages : 13 Date : 2015-05-12 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 10:20:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179B81B30DA for ; Wed, 13 May 2015 10:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP_H179WSveu for ; Wed, 13 May 2015 10:20:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E061B30DD for ; Wed, 13 May 2015 10:20:54 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.160.19; Wed, 13 May 2015 17:20:35 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) with mapi id 15.01.0160.009; Wed, 13 May 2015 17:20:35 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-05.txt Thread-Index: AQHQjSX+Em4wpYlgv0ik72FYH2rL/5155N2A Date: Wed, 13 May 2015 17:20:33 +0000 Message-ID: References: <20150513023827.20745.19141.idtracker@ietfa.amsl.com> In-Reply-To: <20150513023827.20745.19141.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(54534003)(51704005)(377424004)(53754006)(164054003)(377454003)(83506001)(110136002)(76176999)(54356999)(99286002)(189998001)(230783001)(36756003)(2656002)(87936001)(46102003)(2900100001)(92566002)(450100001)(86362001)(62966003)(2950100001)(77156002)(122556002)(107886002)(5001960100002)(50986999)(2501003)(19580405001)(40100003)(19580395003)(106116001)(102836002)(15975445007)(4001350100001)(66066001)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2015 17:20:33.7989 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 17:20:57 -0000 Hi All, The change log entry for this revision is: o Applied many suggestions from WGLC o Removed essay like "Server Identification and Verification" section o Added text for how keep-alives are supported o Added Configuration Data Model section for N/R-client protocol o Improved Security Considerations section Special thanks to Tom, Martin, and Juergen for their thorough reviews last time! Given the lull we're having right now, I am hoping that people have time to do a quick review? I'm hoping that folks can do that while I'm updating the server-model draft in the background. Come on, this is a small document, there's only about nine pages of actual text in it... ;) Thanks, Kent On 5/12/15, 10:38 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Call Home and RESTCONF Call Home > Author : Kent Watsen > Filename : draft-ietf-netconf-call-home-05.txt > Pages : 13 > Date : 2015-05-12 > >Abstract: > This RFC presents NETCONF Call Home and RESTCONF Call Home, which > enable a NETCONF or RESTCONF server to initiate a secure connection > to a NETCONF or RESTCONF client respectively. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-netconf-call-home-05 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-call-home-05 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Thu May 14 13:45:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E581A888B for ; Thu, 14 May 2015 13:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3e0Pl0k24zN for ; Thu, 14 May 2015 13:45:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE0D1A885B for ; Thu, 14 May 2015 13:45:27 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 20:45:26 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) with mapi id 15.01.0160.009; Thu, 14 May 2015 20:45:26 +0000 From: Kent Watsen To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [Netconf] server-model #32: rename "application" to netconf/restconf-client Thread-Index: AQHQZytw+swcmb/HLkawTjQzKpdsqZ17/GUA Date: Thu, 14 May 2015 20:45:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(377454003)(2656002)(99286002)(2501003)(1941001)(83506001)(102836002)(15975445007)(106116001)(107886002)(5001960100002)(2900100001)(46102003)(66066001)(50986999)(76176999)(54356999)(189998001)(5001770100001)(4001350100001)(92566002)(122556002)(36756003)(62966003)(77156002)(16236675004)(2950100001)(40100003)(19580395003)(19617315012)(87936001)(86362001)(19580405001)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D17A80F7A4E2Akwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 20:45:25.1122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: Re: [Netconf] server-model #32: rename "application" to netconf/restconf-client X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:45:29 -0000 --_000_D17A80F7A4E2Akwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This issue is now verified - the next draft will replace "application" with= "netconf/restconf client" - this in the YANG module and also the text... Kent From: Kent Watsen > Date: Wednesday, March 25, 2015 at 2:42 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #32: rename "application" to netconf/restco= nf-client This issue was discussed yesterday with an agreement to make this change (s= ee subject line), both in the YANG modules and in the text throughout in th= e draft. The issue is hence moved to the VERIFY state. The issue will mov= e to the EDIT state If no objection is raised by April 6th. https://github.com/netconf-wg/server-model/issues/32 Thanks, Kent --_000_D17A80F7A4E2Akwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

This issue is now verified – the next draft will replace "a= pplication" with "netconf/restconf client" - this in the YAN= G module and also the text...

Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Wednesday, March 25, 2015 at = 2:42 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #32= : rename "application" to netconf/restconf-client


This issue was discussed yesterday with an agreement to make this chan= ge (see subject line), both in the YANG modules and in the text throughout = in the draft.  The issue is hence moved to the VERIFY state.  The= issue will move to the EDIT state If no objection is raised by April 6th.


Thanks,
Kent

 --_000_D17A80F7A4E2Akwatsenjunipernet_-- From nobody Thu May 14 13:47:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885201A887D for ; Thu, 14 May 2015 13:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq_0KhaM9Wqi for ; Thu, 14 May 2015 13:47:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25031A886F for ; Thu, 14 May 2015 13:47:47 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 20:47:45 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) with mapi id 15.01.0160.009; Thu, 14 May 2015 20:47:45 +0000 From: Kent Watsen To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [Netconf] server-model #33: Is it a good idea to name the top-level node "netconf-server"? Thread-Index: AQHQjoc68ic53hu5kkCMhxIYh1S27g== Date: Thu, 14 May 2015 20:47:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(377454003)(2656002)(99286002)(2501003)(1941001)(83506001)(102836002)(15975445007)(106116001)(107886002)(5001960100002)(2900100001)(46102003)(66066001)(50986999)(54356999)(189998001)(5001770100001)(4001350100001)(92566002)(122556002)(36756003)(62966003)(77156002)(16236675004)(40100003)(19580395003)(19617315012)(87936001)(86362001)(19580405001)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D17A81D7A4E39kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 20:47:45.0718 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: Re: [Netconf] server-model #33: Is it a good idea to name the top-level node "netconf-server"? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:47:49 -0000 --_000_D17A81D7A4E39kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This issue is now considered DEAD. Thanks, Kent From: Kent Watsen > Date: Wednesday, March 25, 2015 at 2:51 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #33: Is it a good idea to name the top-leve= l node "netconf-server"? This issue was discussed yesterday and again this morning. The current agr= eement is to leave the top-level name as it is. The issue is hence moved t= o the VERIFY state. The issue will move to the DEAD state If no objection = is raised by April 6th. https://github.com/netconf-wg/server-model/issues/33 Thanks, Kent --_000_D17A81D7A4E39kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

This issue is now considered DEAD.

Thanks,
Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Wednesday, March 25, 2015 at = 2:51 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #33= : Is it a good idea to name the top-level node "netconf-server"?<= br>



This issue was discussed yesterday a= nd again this morning.  The current agreement is to leave the top-leve= l name as it is.  The issue is hence moved to the VERIFY state.  The issue will move to the DEAD state If no objection is raised by A= pril 6th.


Thanks,
Kent

 --_000_D17A81D7A4E39kwatsenjunipernet_-- From nobody Thu May 14 13:51:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD301A897B for ; Thu, 14 May 2015 13:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeNoPsgN_A6u for ; Thu, 14 May 2015 13:51:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8891A8974 for ; Thu, 14 May 2015 13:51:03 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 20:51:02 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) with mapi id 15.01.0160.009; Thu, 14 May 2015 20:51:02 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #34: Are the features granular enough? Thread-Index: AQHQjoevqiCejXUcYE++G4iUkyyp4Q== Date: Thu, 14 May 2015 20:51:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(164054003)(377454003)(2351001)(2656002)(99286002)(2501003)(83506001)(102836002)(15975445007)(106116001)(107886002)(5001960100002)(2900100001)(110136002)(46102003)(66066001)(50986999)(54356999)(189998001)(81156007)(4001350100001)(92566002)(122556002)(36756003)(62966003)(77156002)(16236675004)(40100003)(19580395003)(19617315012)(87936001)(86362001)(19580405001)(450100001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: multipart/alternative; boundary="_000_D17A826EA4E42kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 20:51:01.1432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: Re: [Netconf] server-model #34: Are the features granular enough? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:51:05 -0000 --_000_D17A826EA4E42kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This issue is verified. The server-model draft will use the YANG 1.1 if-fe= ature statements, as we had them before... Kent From: Kent Watsen > Date: Wednesday, March 25, 2015 at 3:29 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #34: Are the features granular enough? This issue was discussed yesterday with no clear agreement on what to do bu= t, when discussing issue #49, there was an agreement to use the YANG 1.1 if= -feature statement, which we could apply to this issue as well. Specifically, we can go back to the feature statements we had in -04: ssh-l= isten, tls-listen, ssh-call-home, and tls-call-home and use statements like= "if-feature "(ssh-listen or tls-listen)". Essentially, to revert this change: https://github.com/netconf-wg/server-mo= del/commit/c5ae65b679b9dceff91a2fe03f86330123e88f2a This issue will move to the EDIT state, with the plan to revert to the -04 = features, if no objection is raised by April 6th. https://github.com/netconf-wg/server-model/issues/34 Thanks, Kent --_000_D17A826EA4E42kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <603D215C57EEDD44975203E138418819@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
This issue is verified.  The server-model draft will use the YANG= 1.1 if-feature statements, as we had them before...

Kent




From: Kent Watsen <kwatsen@juniper.net>
Date: Wednesday, March 25, 2015 at = 3:29 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #34= : Are the features granular enough?


This issue was discussed yesterday with n= o clear agreement on what to do but, when discussing issue #49, there was a= n agreement to use the YANG 1.1 if-feature statement, which we = could apply to this issue as well.   

Specifically, we can go back to the featu= re statements we had in = –04: ssh-listen, tls-li= sten, ssh-call-home, and tls-call-home and use statements like "if-feature "(ssh-listen or tls-listen)".  &nbs= p;


This issue will move to the EDIT sta= te, with the plan to revert to the -04 features, if no objection is ra= ised by April 6th.


Thanks,
Kent

 --_000_D17A826EA4E42kwatsenjunipernet_-- From nobody Thu May 14 13:53:44 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A955D1A8A17 for ; Thu, 14 May 2015 13:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv2yH6toLANh for ; Thu, 14 May 2015 13:53:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19BB1A8A15 for ; Thu, 14 May 2015 13:53:35 -0700 (PDT) Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by CO1PR05MB329.namprd05.prod.outlook.com (10.141.69.25) with Microsoft SMTP Server (TLS) id 15.1.136.25; Thu, 14 May 2015 20:53:33 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 20:53:32 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) with mapi id 15.01.0160.009; Thu, 14 May 2015 20:53:32 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #38: remove upper-bound on hello-timeout, idle-timeout, and max-sessions? Thread-Index: AQHQjogJdetNemTQnEeqLG8ZVeNWgA== Date: Thu, 14 May 2015 20:53:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB329; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(377454003)(2351001)(2656002)(99286002)(2501003)(83506001)(102836002)(15975445007)(106116001)(107886002)(5001960100002)(2900100001)(110136002)(46102003)(66066001)(50986999)(54356999)(189998001)(4001350100001)(92566002)(122556002)(36756003)(62966003)(77156002)(16236675004)(40100003)(19580395003)(19617315012)(87936001)(86362001)(19580405001)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D17A8309A4E4Ekwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 20:53:32.6621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] server-model #38: remove upper-bound on hello-timeout, idle-timeout, and max-sessions? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:53:40 -0000 --_000_D17A8309A4E4Ekwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The solution below is now verified - the upper-bounds will be removed. K. From: Kent Watsen > Date: Wednesday, March 25, 2015 at 3:55 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #38: remove upper-bound on hello-timeout, i= dle-timeout, and max-sessions? This issue was discussed yesterday with an agreement to remove these upper = bounds from the YANG module. It is understood that servers may have upper-= bounds, and would return an error if a client attempts to configure past an= y of them. The issue is hence moved to the VERIFY state. The issue will m= ove to the EDIT state If no objection is raised by April 6th. How this issue will be implemented will be guided by the resolution to issu= e #39. https://github.com/netconf-wg/server-model/issues/38 Thanks, Kent --_000_D17A8309A4E4Ekwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

The solution below is now verified - the upper-bounds will be removed.=

K.


From: Kent Watsen <kwatsen@juniper.net>
Date: Wednesday, March 25, 2015 at = 3:55 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #38= : remove upper-bound on hello-timeout, idle-timeout, and max-sessions?


This issue was discussed yesterday w= ith an agreement to remove these upper bounds from the YANG module. &n= bsp;It is understood that servers may have upper-bounds, and would return a= n error if a client attempts to configure past any of them.  The issue is hence moved to the VERIFY state. &n= bsp;The issue will move to the EDIT state If no objection is raised by Apri= l 6th.

How this issue will be implemented w= ill be guided by the resolution to issue #39. 


Thanks,
Kent

 --_000_D17A8309A4E4Ekwatsenjunipernet_-- From nobody Thu May 14 13:56:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50281A8877 for ; Thu, 14 May 2015 13:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgpSvxmKSrGB for ; Thu, 14 May 2015 13:55:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3411A8853 for ; Thu, 14 May 2015 13:55:59 -0700 (PDT) Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 20:55:58 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 20:55:58 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) with mapi id 15.01.0160.009; Thu, 14 May 2015 20:55:58 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #39: move away from a number with a fixed unit? Thread-Index: AQHQakBTwhOo1Z+47kaN9en13xmjZZ17+S6A Date: Thu, 14 May 2015 20:55:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(377454003)(2351001)(2656002)(99286002)(2501003)(83506001)(102836002)(15975445007)(106116001)(107886002)(5001960100002)(2900100001)(110136002)(46102003)(66066001)(50986999)(76176999)(54356999)(189998001)(4001350100001)(92566002)(122556002)(36756003)(62966003)(77156002)(16236675004)(2950100001)(40100003)(19580395003)(19617315012)(87936001)(86362001)(19580405001)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D17A83B9A4E5Akwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 20:55:57.1616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] server-model #39: move away from a number with a fixed unit? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:56:01 -0000 --_000_D17A83B9A4E5Akwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The proposed solution to this issue is now verified - we will leave it as u= nits as seconds (no duration) K. From: Kent Watsen > Date: Sunday, March 29, 2015 at 12:49 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #39: move away from a number with a fixed u= nit? This issue was discussed during the Dallas meeting with an agreement to lea= ve as seconds (not use xsd's duration). The issue is hence moved to the VER= IFY state. The issue will move to the EDIT state If no objection is raised= by April 6th. https://github.com/netconf-wg/server-model/issues/39 Thanks, Kent --_000_D17A83B9A4E5Akwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
The proposed solution to this issue is now verified – we will le= ave it as units as seconds (no duration)

K.


From: Kent Watsen <kwatsen@juniper.net>
Date: Sunday, March 29, 2015 at 12:= 49 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #39= : move away from a number with a fixed unit?


This issue was discussed during the = Dallas meeting with an agreement to leave as seconds (not use xsd's duratio= n). The issue= is hence moved to the VERIFY state.  The issue will move to the EDIT state If no objection is raised by April 6th.<= /span>


Thanks,
Kent

 --_000_D17A83B9A4E5Akwatsenjunipernet_-- From nobody Thu May 14 15:53:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C051ACF60 for ; Thu, 14 May 2015 15:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvMn8s-A27-d for ; Thu, 14 May 2015 15:52:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44471ACF58 for ; Thu, 14 May 2015 15:52:57 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 22:52:56 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) with mapi id 15.01.0160.009; Thu, 14 May 2015 22:52:56 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #40: move "max-sessions" to global session-param? Thread-Index: AQHQakEEonOI9XVYPEiBtltJ0PPLkJ18Gd2A Date: Thu, 14 May 2015 22:52:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(36756003)(86362001)(2501003)(16236675004)(19580405001)(2900100001)(19580395003)(2950100001)(83506001)(50986999)(54356999)(76176999)(77156002)(62966003)(450100001)(40100003)(102836002)(5001960100002)(107886002)(110136002)(189998001)(122556002)(66066001)(87936001)(106116001)(46102003)(4001350100001)(2656002)(2351001)(92566002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D17A9F3CA4F8Dkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 22:52:56.0606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: Re: [Netconf] server-model #40: move "max-sessions" to global session-param? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 22:52:59 -0000 --_000_D17A9F3CA4F8Dkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The solution to this issue has been verified. Thanks, Kent From: Kent Watsen > Date: Sunday, March 29, 2015 at 12:54 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #40: move "max-sessions" to global session-= param? This issue was discussed during and after the Dallas meeting with an agreem= ent to leave the "max-sessions" under the "listen" container. This because= only call-home connections are not variable in number. The issue is hence= moved to the VERIFY state. The issue will move to the EDIT state if no ob= jection is raised by April 6th. Thanks, Kent --_000_D17A9F3CA4F8Dkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <1891F8BCEDF2A8418AA85EBDDE9BA443@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
The solution to this issue has been verified.

Thanks,
Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Sunday, March 29, 2015 at 12:= 54 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #40= : move "max-sessions" to global session-param?


This issue was discussed during and after the Dallas meeting with an a= greement to leave the "max-sessions" under the "listen"= container.  This because only call-home connections are not variable = in number.  The issue is hence moved to the VERIFY state.  The issue will move to the EDIT state if no objection is raised by A= pril 6th.

Thanks,
Kent

 --_000_D17A9F3CA4F8Dkwatsenjunipernet_-- From nobody Thu May 14 15:55:35 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7061ACEAD for ; Thu, 14 May 2015 15:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_KTsiv_CeGB for ; Thu, 14 May 2015 15:55:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012BF1ACF58 for ; Thu, 14 May 2015 15:55:30 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 22:55:30 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) with mapi id 15.01.0160.009; Thu, 14 May 2015 22:55:29 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #41: should address be mandatory? Thread-Index: AQHQjpkS6f2FfS0egkWKsdyiIqJ5Lw== Date: Thu, 14 May 2015 22:55:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(36756003)(86362001)(2501003)(16236675004)(19617315012)(19580405001)(2900100001)(19580395003)(83506001)(50986999)(54356999)(77156002)(62966003)(450100001)(40100003)(15975445007)(102836002)(5001960100002)(107886002)(110136002)(189998001)(122556002)(66066001)(87936001)(106116001)(46102003)(4001350100001)(2656002)(2351001)(92566002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D17A9FB2A4F96kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 22:55:28.9835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: Re: [Netconf] server-model #41: should address be mandatory? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 22:55:32 -0000 --_000_D17A9FB2A4F96kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The solution to this issue proposed below is now verified. Kent From: Kent Watsen > Date: Sunday, March 29, 2015 at 1:00 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #41: should address be mandatory? This issue was discussed during the Dallas meeting with an agreement to lea= ve as mandatory false and add to the description that a missing address is = to be interpreted as a wildcard meaning "all interfaces". The issue is hence moved to the VERIFY state. The issue will move to the E= DIT state If no objection is raised by April 6th. https://github.com/netconf-wg/server-model/issues/41 Thanks, Kent --_000_D17A9FB2A4F96kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The solution to this issue proposed below is now verified.

Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Sunday, March 29, 2015 at 1:0= 0 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #41= : should address be mandatory?


This issue was discussed during the = Dallas meeting with an agreement to leave as mandatory false and add t= o the description that a missing address is to be interpreted as a wildcard= meaning "all interfaces".

The issue is hence moved to the VERIFY st= ate.  The issue will move to the EDIT state If no objection is raised = by April 6th.


Thanks,
Kent
 --_000_D17A9FB2A4F96kwatsenjunipernet_-- From nobody Thu May 14 16:06:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCEB1A90AD for ; Thu, 14 May 2015 16:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojLKpeOr-xUc for ; Thu, 14 May 2015 16:06:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0793.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::793]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4091A1A58 for ; Thu, 14 May 2015 16:06:32 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB363.namprd05.prod.outlook.com (10.141.51.145) with Microsoft SMTP Server (TLS) id 15.1.154.19; Thu, 14 May 2015 23:06:12 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) with mapi id 15.01.0160.009; Thu, 14 May 2015 23:06:12 +0000 From: Kent Watsen To: Phil Shafer Thread-Topic: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK? Thread-Index: AQHQalr5OEpeLICj8UOqu96zVYFF7Z00eRaAgEekRwA= Date: Thu, 14 May 2015 23:06:10 +0000 Message-ID: References: <201503300503.t2U53jqh084141@idle.juniper.net> In-Reply-To: <201503300503.t2U53jqh084141@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB363; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB363; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB363; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(164054003)(377454003)(479174004)(2656002)(99286002)(1941001)(83506001)(102836002)(106116001)(5001960100002)(2900100001)(110136002)(46102003)(66066001)(50986999)(76176999)(54356999)(189998001)(4001350100001)(92566002)(122556002)(36756003)(62966003)(77156002)(2950100001)(40100003)(19580395003)(87936001)(86362001)(19580405001)(450100001)(4001450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB363; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <0ACE30E8AA5A8D4C970FB8D04040FA31@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 23:06:10.9598 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB363 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 23:06:34 -0000 On 3/30/15, 1:03 AM, "Phil Shafer" wrote: >Kent Watsen writes: >>Note, this is a >>keep-alive message being sent every 15 to 300 seconds, with a default >>count-max of '3', results in a new connection after 45 to 900 seconds - >>that's 3/4 of a minute to 15 minutes to proactively bring up a failed >>session. > >Having a connection to your NMS die after 45 seconds during a network >issue, when the network _is_ having trouble, seems unwise. Hi Phil, This timer is to test the aliveness of the connection. Sure, if the NMS doesn't respond in time, the device tears down that connection in hope to find a connection the works better. 45 seconds seems too short to you, and 15 minutes seems too long to me. How about 5 minutes for the default? Anyone else have an opinion? Thanks, Kent From nobody Fri May 15 11:46:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FA11A1BD9 for ; Fri, 15 May 2015 11:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q1jRi4rlymS for ; Fri, 15 May 2015 11:46:43 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D131A1B43 for ; Fri, 15 May 2015 11:46:43 -0700 (PDT) Received: by lagv1 with SMTP id v1so133668871lag.3 for ; Fri, 15 May 2015 11:46:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T0Nt9gqF1LDq+se4oGXyzi3w77Dgz0QQutdcUEhs+e8=; b=aTy0uO3n3J9Xa0fqLOMyIl0E8Gehh3gttsxhmjqFc2ZvXOvVx3oGF97Km6d2IrIzcX njdedY1O2QOvDrw04b9NUj6PNJ+UWCaC40qKEeGqACOpMfPtbNxuFDYE2z5NRTmiieio pstOKIKMzTQSsY2m07y8ub6u4XDyQpnk4T30XV6J8ITpL/PvsRwFXznkkYcspUN2dJH3 bu1y1k38i+SdljtIUUIlOZiLMJw7gkgJmKvPGL7wtL7lZFaV66vT5IXOO7c7uk1woSqF YAqfRzjES9VVoe6lA1BCXSC6iu1HpcO/qnkZ7OS7LZHQEr40QtZ6lKmcSIQLbuhE6N8Z tktw== X-Gm-Message-State: ALoCoQkp7EdntS9qWxE/QwSeJiHyRFGzEc4TLRz4BzKdbrBwCUe+IQOySvl/W/XDCjsfFJ+N4Hln MIME-Version: 1.0 X-Received: by 10.112.56.42 with SMTP id x10mr8231558lbp.123.1431715601838; Fri, 15 May 2015 11:46:41 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 15 May 2015 11:46:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 May 2015 11:46:41 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF #21: operation input output encoding X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 18:46:45 -0000 Hi, There has not been any discussion on this issue so I guess we should leave the operation encoding unchanged. Andy On Mon, May 4, 2015 at 2:34 PM, Andy Bierman wrote: > On Mon, May 4, 2015 at 2:19 PM, Kent Watsen wrote: >> >>>A new RESTCONF issue has been added: >>> >>>https://github.com/netconf-wg/restconf/issues/21 >>> >>>This issue proposes to change the encoding of operation >>>input and output parameters: >>> >>> - change "input" tp rpc name >>> - change "output" to rpc-name >>> >>>If there are no objections by May 7, then this >>>change will be added to the next draft (-05). >> >> >> Hi Andy, >> >> I don't agree to this, at least not without discussion. >> >> We (Martin, you, and myself) discussed this (and action statements) >> privately on Mar 31 and again on Apr 9/10 - a total of 26 messages, where >> we landed on sticking with the input/output top-level elements - what's >> changed? Given that the current encoding has been with us since the >> beginning, changing it now needs to be done with care. >> >> Personally, I find the input/output elements more useful, as already the >> URL encodes the name of the RPC - having the RPC's name again in the body >> of the message seems redundant, whereas input/output provides context. >> Additionally, keep in mind that, with action statements, there can be many >> actions with the same name. For this reason, it's never possible to >> process an input or output message body without context (e.g., pyang would >> have to have a parameter indicated *which* action statement to assume). >> Is your motivation for this change to enable contextless processing? >> > > > The problem is that all RPCs from the same module look the same > and there is no way to associate the data with the operation other > than knowing the request URI that goes with the data > > .... > > ... > > OR > > > ... > > ... > > The is what we do in NETCONF. > RESTCONF is supposed to be consistent with NETCONF unless there > is a good reason to do otherwise. > > >> Thanks, >> Kent > > Andy > >> >> >> >> >> From nobody Mon May 18 14:49:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF511AC40F for ; Mon, 18 May 2015 14:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or3HjnA5qn5J for ; Mon, 18 May 2015 14:49:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8291A1A4A for ; Mon, 18 May 2015 14:49:44 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) with Microsoft SMTP Server (TLS) id 15.1.166.22; Mon, 18 May 2015 21:49:43 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) with mapi id 15.01.0166.017; Mon, 18 May 2015 21:49:43 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #45: how do interval-secs and count-max work for reconnect-strategy if an endpoint resolves to multiple IP addresses? Thread-Index: AQHQkbSMWqU4gi9S0UeqsWKl3l5xvw== Date: Mon, 18 May 2015 21:49:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB456; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB456; x-forefront-prvs: 058043A388 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(164054003)(377454003)(199003)(106356001)(122556002)(5001830100001)(4001350100001)(64706001)(5001960100002)(99286002)(107886002)(110136002)(105586002)(189998001)(106116001)(62966003)(2351001)(450100001)(15975445007)(102836002)(77156002)(2900100001)(4001540100001)(19617315012)(97736004)(40100003)(81156007)(68736005)(5001860100001)(36756003)(46102003)(19580405001)(19580395003)(92566002)(83506001)(101416001)(54356999)(50986999)(86362001)(2501003)(16236675004)(87936001)(66066001)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB456; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D17FD672A5B37kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2015 21:49:42.8506 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB456 Archived-At: Subject: Re: [Netconf] server-model #45: how do interval-secs and count-max work for reconnect-strategy if an endpoint resolves to multiple IP addresses? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 21:49:46 -0000 --_000_D17FD672A5B37kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The solution to this issue, as described below, is now considered verified. Kent From: Kent Watsen > Date: Sunday, March 29, 2015 at 4:27 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #45: how do interval-secs and count-max wor= k for reconnect-strategy if an endpoint resolves to multiple IP addresses? This issue (see subject line and/or link below) was discussed during the Da= llas meeting with an agreement simply document that hostname expansions occ= ur in-line. That is, if an application has two configured endpoints ("name= 1" and "name2") and each expands into two IP addresses ({ip1.1, ip1.2, ip1.= 3}, {ip2.1, ip2.2, ip2.3}), then treat them as if the IP addresses had been= configured explicitly (ip1.1, ip1.2, ip1.3, ip2.1, ip2.2, ip2.3). The issue is hence moved to the VERIFY state. The issue will move to the E= DIT state If no objection is raised by April 6th. Reference: https://github.com/netconf-wg/server-model/issues/45 Thanks, Kent --_000_D17FD672A5B37kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The solution to this issue, as described below, is now considered veri= fied.

Kent

From: Kent Watsen <kwatsen@juniper.net>
Date: Sunday, March 29, 2015 at 4:2= 7 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #45= : how do interval-secs and count-max work for reconnect-strategy if an endp= oint resolves to multiple IP addresses?


This issue (see subject line and/or link = below) was discussed during the Dallas meeting with an agreement simply= document that hostname expansions occur in-line.  That is, if an application has two configured e= ndpoints ("name1" and "name2") and each expands into tw= o IP addresses ({ip1.1, ip1.2, ip1.3}, {ip2.1, ip2.2, ip2.3}), then treat t= hem as if the IP addresses had been configured explicitly (ip1.1, ip1.2, ip1.3, ip2.1, ip2.2, ip2.3).

The issue is hence moved to the VERIFY st= ate.  The issue will move to the EDIT state If no objection is raised = by April 6th.


Thanks,
Kent
 --_000_D17FD672A5B37kwatsenjunipernet_-- From nobody Mon May 18 14:59:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A071ACD78 for ; Mon, 18 May 2015 14:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyfILO2nE2uK for ; Mon, 18 May 2015 14:59:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8C91ACD77 for ; Mon, 18 May 2015 14:59:51 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB455.namprd05.prod.outlook.com (10.141.59.24) with Microsoft SMTP Server (TLS) id 15.1.166.22; Mon, 18 May 2015 21:59:30 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) with mapi id 15.01.0166.017; Mon, 18 May 2015 21:59:30 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #46: move "peer_allowed_to_send" to Call Home draft? Thread-Index: AQHQam1OLVdFk/Tgw0OjXWX6/Gw/V52CU+iA Date: Mon, 18 May 2015 21:59:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB455; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB455; x-forefront-prvs: 058043A388 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(24454002)(479174004)(377454003)(189002)(164054003)(50986999)(122556002)(107886002)(92566002)(110136002)(54356999)(5001830100001)(83506001)(5001860100001)(2351001)(76176999)(99286002)(36756003)(40100003)(561944003)(101416001)(5001960100002)(105586002)(2656002)(19580405001)(189998001)(450100001)(19580395003)(87936001)(64706001)(81156007)(4001540100001)(4001350100001)(62966003)(97736004)(2501003)(106356001)(46102003)(77156002)(106116001)(68736005)(86362001)(2950100001)(15975445007)(102836002)(66066001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB455; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <657D1DB3E6B9C6448E8084BF1F50CE8C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2015 21:59:29.3132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB455 Archived-At: Subject: Re: [Netconf] server-model #46: move "peer_allowed_to_send" to Call Home draft? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 21:59:54 -0000 Please note that the recently posted call-home-05 draft now specifies keep-alive requirements. For the server-model draft, my proposal is to: - remove the keep-alive configuration from the "listen" tree - not add any knobs for tcp timeouts This proposal will be considered verified on May 23rd, if not objections are raised by then... Kent On 3/29/15, 5:11 PM, "Kent Watsen" wrote: > >This issue (see subject line and link below) was discussed during the >Dallas meeting with no clear agreement, so bringing the discussion to the >list now. > >As Juergen questioned originally, if configuring keep-alives (and perhaps >tcp timeouts) is important, then the call-home draft should say something >about it. This makes sense as the call-home draft intends to describe >the protocol, leaving the server-model draft to focus on the yang modules. > One issue arises, though, in that the server-model uses keep-alives >under both the "call-home" and "listen" subtrees. We may want to remove >the keep-alive configuration under the "listen" subtree, where it only >supports a low-value use-case. If we remove it, then it clears the way to >adding text to the call-home draft, as only the "call-home" subtree would >be left in the netconf/restconf yang modules. > >Note: This issue is related to server-model #43 [1], which is about the >default value for /keep-alives/interval-secs, and asks if the server-model >should have a knob to configure the tcp timeout value. If we agree that >there should be a knob to configure the tcp timeout, then the call-home >draft should discuss this in the same section where is would discuss the >need for SSH/TLS-level keep-alives. > > >This issue is hence moved to the OPEN (not VERIFY) state. The issue will >move to the VERIFY state with the above proposal if no objection is raised >by April 6th. > >Reference: https://github.com/netconf-wg/server-model/issues/46 > >Thanks, >Kent > > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon May 18 15:09:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1AE1A86EE for ; Mon, 18 May 2015 15:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_mvyrBHqgtg for ; Mon, 18 May 2015 15:09:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A641A8033 for ; Mon, 18 May 2015 15:09:18 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.166.22; Mon, 18 May 2015 22:09:16 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) with mapi id 15.01.0166.017; Mon, 18 May 2015 22:09:16 +0000 From: Kent Watsen To: Randy Presuhn , "netconf@ietf.org" Thread-Topic: [Netconf] server-model #47: introduce a 2nd timeout for periodic connections for when there's data to send? Thread-Index: AQHQaycWfJQQsffhLU+ZVRb/ga6GhJ2CVTAA Date: Mon, 18 May 2015 22:09:15 +0000 Message-ID: References: <30896412.1427746746472.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> In-Reply-To: <30896412.1427746746472.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; x-forefront-prvs: 058043A388 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(189002)(86362001)(64706001)(122556002)(189998001)(77156002)(46102003)(4001540100001)(5001770100001)(4001350100001)(107886002)(5001960100002)(5001830100001)(5001920100001)(97736004)(81156007)(5001860100001)(66066001)(50986999)(54356999)(106356001)(76176999)(106116001)(62966003)(68736005)(105586002)(102836002)(92566002)(99286002)(2501003)(2656002)(83506001)(101416001)(36756003)(40100003)(2900100001)(2950100001)(87936001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <9451E7C2B2ACB94BAA92D10ECE3B52D4@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2015 22:09:15.9570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453 Archived-At: Subject: Re: [Netconf] server-model #47: introduce a 2nd timeout for periodic connections for when there's data to send? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 22:09:20 -0000 >>OLD: >> >> For messages the NETCONF server wants to send to >> to the NETCONF client, the NETCONF server should >> proactively connect to the NETCONF client, if >> not already, to send the messages immediately."; >> >>NEW >> >> For messages the NETCONF server wants to send to >> to the NETCONF client, the NETCONF server may >> proactively connect to the NETCONF client, if >> not already, to send its messages sooner than >> its periodic timeout would have it do."; > >The English is broken. > s/, if not already,/ (if it is not already connected)/ > >The English is awkward. > s/its periodic timeout would have it do/specified by its periodic >timeout/ > >Anthropomorphisms are annoying: > s/the NETCONF server wants to send/to be sent by the NETCONF server/ Taking Randy's comments into account, and trimming it down to a more direct statement: For messages to be sent by the NETCONF server to the NETCONF client, the NETCONF server may proactively connect to the NETCONF client sooner than specified by its periodic timeout. Kent From nobody Mon May 18 15:14:35 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2E01A871C for ; Mon, 18 May 2015 15:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMeUCPZe-9gb for ; Mon, 18 May 2015 15:14:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0EB91A6FFF for ; Mon, 18 May 2015 15:14:32 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) with Microsoft SMTP Server (TLS) id 15.1.166.22; Mon, 18 May 2015 22:14:31 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) with mapi id 15.01.0166.017; Mon, 18 May 2015 22:14:31 +0000 From: Kent Watsen To: t.petch , "netconf@ietf.org" Thread-Topic: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? Thread-Index: AQHQanT/BncK8ydKj0azKXFdHxn57502PmvXgEwZogA= Date: Mon, 18 May 2015 22:14:31 +0000 Message-ID: References: <00f901d06b89$82faa3e0$4001a8c0@gateway.2wire.net> In-Reply-To: <00f901d06b89$82faa3e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB456; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB456; x-forefront-prvs: 058043A388 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(24454002)(13464003)(199003)(377454003)(189002)(164054003)(51704005)(479174004)(83506001)(19580405001)(92566002)(19580395003)(101416001)(230783001)(87936001)(66066001)(2656002)(54356999)(86362001)(2501003)(50986999)(76176999)(64706001)(105586002)(189998001)(106116001)(99286002)(5001960100002)(107886002)(106356001)(4001350100001)(5001830100001)(122556002)(81156007)(68736005)(5001770100001)(36756003)(46102003)(5001860100001)(62966003)(2950100001)(97736004)(40100003)(102836002)(77156002)(15975445007)(2900100001)(4001540100001)(7059030)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB456; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2015 22:14:31.5298 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB456 Archived-At: Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 22:14:34 -0000 Hi Tom, Yes, if server-model uses YANG 1.1 syntax, than both the clients and servers will need to support YANG 1.1 in order to support the server-model YANG module. Thanks, Kent On 3/31/15, 4:05 AM, "t.petch" wrote: >----- Original Message ----- >From: "Kent Watsen" >To: >Sent: Monday, March 30, 2015 12:06 AM > >This issue (see subject line and/or link below) was discussed during the >Dallas meeting with an agreement to combine the configuration for >trusted CA-certs and client-certs into one container for both SSH and >TLS. The new container would use the following YANG 1.1 if-feature >statement (assuming the WG adopts that resolution): > > > >Does this mean that unless and until the clients and servers are >upgraded to support YANG 1.1, then there will be no YANG server model >that they could use? > >Tom Petch > > > if-feature "(ssh-x509-certs or tls)"; > >This issue is hence moved to the VERIFY state. The issue will move to >the EDIT state if no objection is raised by April 6th. > >Reference: https://github.com/netconf-wg/server-model/issues/49 > >Thanks, >Kent > > > > >------------------------------------------------------------------------ >-------- > > >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > From nobody Mon May 18 15:15:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1FE1A86EC for ; Mon, 18 May 2015 15:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWWeEx-9gJYg for ; Mon, 18 May 2015 15:15:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636F51A6FFF for ; Mon, 18 May 2015 15:15:33 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) with Microsoft SMTP Server (TLS) id 15.1.166.22; Mon, 18 May 2015 22:15:32 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) with mapi id 15.01.0166.017; Mon, 18 May 2015 22:15:32 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? Thread-Index: AQHQkbgnBncK8ydKj0azKXFdHxn57w== Date: Mon, 18 May 2015 22:15:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB456; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB456; x-forefront-prvs: 058043A388 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(164054003)(83506001)(19580405001)(92566002)(19580395003)(101416001)(230783001)(87936001)(66066001)(16236675004)(2656002)(54356999)(86362001)(2501003)(50986999)(64706001)(105586002)(189998001)(106116001)(99286002)(5001960100002)(107886002)(110136002)(106356001)(4001350100001)(5001830100001)(122556002)(81156007)(68736005)(36756003)(46102003)(5001860100001)(62966003)(19617315012)(97736004)(40100003)(450100001)(102836002)(77156002)(15975445007)(2351001)(2900100001)(4001540100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB456; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D17FDC93A5B6Bkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2015 22:15:32.2758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB456 Archived-At: Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 22:15:36 -0000 --_000_D17FDC93A5B6Bkwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The solution described below is now considered verified. Thanks, Kent From: Kent Watsen > Date: Sunday, March 29, 2015 at 7:06 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #49: combine trusted-ca-certs and trusted-c= lient-certs for ssh/tls? This issue (see subject line and/or link below) was discussed during the Da= llas meeting with an agreement to combine the configuration for trusted CA-= certs and client-certs into one container for both SSH and TLS. The new co= ntainer would use the following YANG 1.1 if-feature statement (assuming the= WG adopts that resolution): if-feature "(ssh-x509-certs or tls)"; This issue is hence moved to the VERIFY state. The issue will move to the = EDIT state if no objection is raised by April 6th. Reference: https://github.com/netconf-wg/server-model/issues/49 Thanks, Kent --_000_D17FDC93A5B6Bkwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

The solution described below is now considered verified.

Thanks,
Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Sunday, March 29, 2015 at 7:0= 6 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #49= : combine trusted-ca-certs and trusted-client-certs for ssh/tls?


This issue (see subject line and/or = link below) was discussed during the Dallas meeting with an agreement to combine the con= figuration for trusted CA-certs and client-certs into one container for both SSH and TLS.  T= he new container would use the following YANG 1.1 if-feature statement (ass= uming the WG adopts that resolution):

    if-feature “(ssh-x509-certs or tls)”;

This issue is hence moved to the VER= IFY state.  The issue will move to the EDIT state if no objection is raised by Apri= l 6th.


Thanks,
Kent

--_000_D17FDC93A5B6Bkwatsenjunipernet_-- From nobody Mon May 18 15:23:59 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1243C1ACD63 for ; Mon, 18 May 2015 15:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgduUP-F6RDx for ; Mon, 18 May 2015 15:23:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A441ACD7E for ; Mon, 18 May 2015 15:23:55 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB359.namprd05.prod.outlook.com (10.141.61.150) with Microsoft SMTP Server (TLS) id 15.1.154.19; Mon, 18 May 2015 22:23:53 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) with mapi id 15.01.0166.017; Mon, 18 May 2015 22:23:52 +0000 From: Kent Watsen To: Kent Watsen , Phil Shafer Thread-Topic: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK? Thread-Index: AQHQalr5OEpeLICj8UOqu96zVYFF7Z00eRaAgEekRwCABj2AAA== Date: Mon, 18 May 2015 22:23:51 +0000 Message-ID: References: <201503300503.t2U53jqh084141@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB359; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB359; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB359; x-forefront-prvs: 058043A388 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(164054003)(479174004)(189002)(24454002)(377454003)(87936001)(106356001)(83506001)(92566002)(46102003)(1941001)(2656002)(5001770100001)(106116001)(99286002)(101416001)(105586002)(54356999)(189998001)(5001960100002)(5001860100001)(5001830100001)(76176999)(50986999)(5001920100001)(66066001)(64706001)(4001350100001)(86362001)(19580395003)(19580405001)(4001540100001)(15975445007)(77156002)(62966003)(68736005)(122556002)(450100001)(97736004)(102836002)(2950100001)(81156007)(40100003)(2900100001)(36756003)(4001450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB359; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <0932F356D48B204A8DFECAAB687BE943@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2015 22:23:51.8288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB359 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 22:23:58 -0000 For the original issue, we now have: [1] .../connection-type/persistent/keep-alives/interval-secs: Set default to 5 minutes [2] .../connection-type/periodic/linger-secs: Remove this node. [3] .../reconnect-strategy/interval-secs: Remove this node. This solution will be considered verified on May 23 if no objections are raised before then. Thanks, Kent On 5/14/15, 7:06 PM, "Kent Watsen" wrote: > > >On 3/30/15, 1:03 AM, "Phil Shafer" wrote: >>Kent Watsen writes: >>>Note, this is a >>>keep-alive message being sent every 15 to 300 seconds, with a default >>>count-max of '3', results in a new connection after 45 to 900 seconds - >>>that's 3/4 of a minute to 15 minutes to proactively bring up a failed >>>session. >> >>Having a connection to your NMS die after 45 seconds during a network >>issue, when the network _is_ having trouble, seems unwise. > > >Hi Phil, > >This timer is to test the aliveness of the connection. Sure, if the NMS >doesn't respond in time, the device tears down that connection in hope to >find a connection the works better. > >45 seconds seems too short to you, and 15 minutes seems too long to me. >How about 5 minutes for the default? Anyone else have an opinion? > >Thanks, >Kent > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon May 18 15:48:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2FE1ACDA9 for ; Mon, 18 May 2015 15:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM1FN0j8AatK for ; Mon, 18 May 2015 15:48:43 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id AD8221A1B51 for ; Mon, 18 May 2015 15:48:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=A4bLXK9dy3yL+Qpule2MVTqwOja+UnJsb425ENP3KrhNSWwRKmXvcGWVDusuxbao; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YuTpy-000424-MN; Mon, 18 May 2015 18:48:42 -0400 Received: from 50.109.196.222 by webmail.earthlink.net with HTTP; Mon, 18 May 2015 18:48:42 -0400 Message-ID: <7782134.1431989322606.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Mon, 18 May 2015 15:48:42 -0700 (GMT-07:00) From: Randy Presuhn To: Kent Watsen , "netconf@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba03076dadd0f03242e3dce822f52b13c2c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 Archived-At: Subject: Re: [Netconf] server-model #47: introduce a 2nd timeout for periodic connections for when there's data to send? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 22:48:45 -0000 Hi - >From: Kent Watsen >Sent: May 18, 2015 3:09 PM >To: Randy Presuhn , "netconf@ietf.org" >Subject: Re: [Netconf] server-model #47: introduce a 2nd timeout for periodic connections for when there's data to send? > > > >>>OLD: >>> >>> For messages the NETCONF server wants to send to >>> to the NETCONF client, the NETCONF server should >>> proactively connect to the NETCONF client, if >>> not already, to send the messages immediately."; >>> >>>NEW >>> >>> For messages the NETCONF server wants to send to >>> to the NETCONF client, the NETCONF server may >>> proactively connect to the NETCONF client, if >>> not already, to send its messages sooner than >>> its periodic timeout would have it do."; >> >>The English is broken. >> s/, if not already,/ (if it is not already connected)/ >> >>The English is awkward. >> s/its periodic timeout would have it do/specified by its periodic >>timeout/ >> >>Anthropomorphisms are annoying: >> s/the NETCONF server wants to send/to be sent by the NETCONF server/ > > >Taking Randy's comments into account, and trimming it down to a more >direct statement: > > For messages to be sent by the NETCONF server > to the NETCONF client, the NETCONF server may > proactively connect to the NETCONF client > sooner than specified by its periodic timeout. Works for me, though I think the new wording makes it clear that the "For messages to be sent by the NETCONF server to the NETCONF client" is really superfluous, and that the "may" should be a "MAY". Randy From nobody Mon May 18 16:22:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16121B2AF9 for ; Mon, 18 May 2015 16:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsx4WkvrPQhl for ; Mon, 18 May 2015 16:22:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391EE1B2B01 for ; Mon, 18 May 2015 16:22:44 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.166.22; Mon, 18 May 2015 23:22:43 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) with mapi id 15.01.0166.017; Mon, 18 May 2015 23:22:43 +0000 From: Kent Watsen To: Randy Presuhn , "netconf@ietf.org" Thread-Topic: [Netconf] server-model #47: introduce a 2nd timeout for periodic connections for when there's data to send? Thread-Index: AQHQkbzJfJQQsffhLU+ZVRb/ga6GhJ2CHIsA Date: Mon, 18 May 2015 23:22:42 +0000 Message-ID: References: <7782134.1431989322606.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> In-Reply-To: <7782134.1431989322606.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; x-forefront-prvs: 058043A388 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51704005)(43784003)(99286002)(92566002)(2501003)(102836002)(105586002)(2950100001)(87936001)(40100003)(2900100001)(83506001)(2656002)(36756003)(101416001)(5001830100001)(4001540100001)(5001960100002)(5001770100001)(107886002)(4001350100001)(81156007)(97736004)(5001860100001)(122556002)(189998001)(86362001)(64706001)(46102003)(77156002)(62966003)(68736005)(54356999)(66066001)(50986999)(76176999)(106116001)(106356001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2015 23:22:42.9041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453 Archived-At: Subject: Re: [Netconf] server-model #47: introduce a 2nd timeout for periodic connections for when there's data to send? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 23:22:46 -0000 >> >> For messages to be sent by the NETCONF server >> to the NETCONF client, the NETCONF server may >> proactively connect to the NETCONF client >> sooner than specified by its periodic timeout. > >Works for me, though I think the new wording makes it >clear that the "For messages to be sent by the NETCONF >server to the NETCONF client" is really superfluous, >and that the "may" should be a "MAY". Good point, is this better? The NETCONF server MAY connect to the NETCONF client sooner than specified by its periodic timeout for any reason (e.g., to send a message). Thanks again, Kent From nobody Wed May 20 17:52:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801D21ACDFA for ; Wed, 20 May 2015 17:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGmrwtPE9SPB for ; Wed, 20 May 2015 17:52:34 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054181ACDE9 for ; Wed, 20 May 2015 17:52:34 -0700 (PDT) Received: by lbcmx3 with SMTP id mx3so6775518lbc.1 for ; Wed, 20 May 2015 17:52:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=WDll3zfiSHfFyJ59CpjlgnUs2iija26PCfT7ALhEDwk=; b=WCRf28EGVM/BUoK2Z6BCA5lLKyMrdcA/cwP/n4dY8mRkOx2osgZZj5DhV4j6sGMM6r 5LH2qlcvRRe4/af7yhoIBPlU2epiPDahk1nb/wVR5AiaN4gmIXV6ui8Dyhd+W/iv3Lo3 bt3J9SWAgFRg7lAB13nsO+X8IBEZWZJ8cfhQZqr1f64Wz+di7pbTbnlja7wroyqJ/ASg DecUtlGUpOiC8qGiW7f0x5bqAcUXS1/HYh+eZ/4/NYJg9GlWhWIjNFwF0K4xCNlx30vx kVUHDDN04hnJ6wgVfOcICXpWxXLpJCWVqbvkvD21amhOMGLPtt4AjQcg32UMJVWTvUYU RMRQ== X-Gm-Message-State: ALoCoQm8WFLsQ+bp7MZpE44qlijTXaDq+c7dmF2JnOfUo51HdNgE6zYYVs1lxN1eVmfnseVNexsL MIME-Version: 1.0 X-Received: by 10.112.199.195 with SMTP id jm3mr104234lbc.38.1432169552514; Wed, 20 May 2015 17:52:32 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 20 May 2015 17:52:32 -0700 (PDT) Date: Wed, 20 May 2015 17:52:32 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] subtree filter content-match node issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 00:52:35 -0000 Hi, I have a couple concerns about the subtree filtering text in RFC 6241. 1) returning content-match nodes Sec. 6.2.5 para 2, bullet 1 says: o Each content match node in the sibling set is included in the filter output. This is redundant data since the only values returned will exactly match the content match leaf itself. IMO, this text should say MAY return the content-match node. 2) attribute test on a content-match node Sec. 6.2.2, para 1 has this text: If an element is not defined to include a specified attribute, then it is not selected in the filter output. It is unclear whether the content-match test result is used if the attribute test fails. IMO the content-match test fails, which causes the entire sibling set to be removed. Another interpretation might be that the test result is used, and if it passes, but the attr-test fails, then only the content-match node is removed from the output. Andy From nobody Wed May 20 22:13:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B618E1A004D for ; Wed, 20 May 2015 22:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F05BwLBSc2X0 for ; Wed, 20 May 2015 22:13:18 -0700 (PDT) Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.231]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419B71A001A for ; Wed, 20 May 2015 22:13:18 -0700 (PDT) Received: from [192.168.2.36] ([73.8.162.228]) by p3plsmtpa09-02.prod.phx3.secureserver.net with id WVDG1q00F4vySjM01VDHne; Wed, 20 May 2015 22:13:17 -0700 Message-ID: <555D696C.7050606@seguesoft.com> Date: Thu, 21 May 2015 00:13:16 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Andy Bierman , Netconf References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] subtree filter content-match node issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 05:13:19 -0000 On 5/20/2015 7:52 PM, Andy Bierman wrote: > Hi, > > I have a couple concerns about the subtree filtering > text in RFC 6241. > > 1) returning content-match nodes > > Sec. 6.2.5 para 2, bullet 1 says: > > o Each content match node in the sibling set is included in the > filter output. > > This is redundant data since the only values returned will > exactly match the content match leaf itself. IMO, this > text should say MAY return the content-match node. I think it should be "MUST". For example, when I am retrieving two instances of a leaf in a list, the reply needs the content match leaf (usually key values) so I can easily tell to which entry a leaf instance belongs. > > 2) attribute test on a content-match node > Sec. 6.2.2, para 1 has this text: > > If an element is not defined to include a > specified attribute, then it is not selected in the filter output. > > It is unclear whether the content-match test result is used > if the attribute test fails. IMO the content-match test fails, > which causes the entire sibling set to be removed. I agree with this interpretation. -Xiang From nobody Thu May 21 00:03:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C862E1A1AAD for ; Thu, 21 May 2015 00:03:51 -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=[BAYES_05=-0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngEGtk78ZdUX for ; Thu, 21 May 2015 00:03:50 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0454C1A1A80 for ; Thu, 21 May 2015 00:03:50 -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 C5BB91AE035C; Thu, 21 May 2015 09:03:47 +0200 (CEST) Date: Thu, 21 May 2015 09:03:47 +0200 (CEST) Message-Id: <20150521.090347.2072460014188530897.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] subtree filter content-match node issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 07:03:51 -0000 Andy Bierman wrote: > Hi, > > I have a couple concerns about the subtree filtering > text in RFC 6241. > > 1) returning content-match nodes > > Sec. 6.2.5 para 2, bullet 1 says: > > o Each content match node in the sibling set is included in the > filter output. > > This is redundant data since the only values returned will > exactly match the content match leaf itself. IMO, this > text should say MAY return the content-match node. I assume that this text was added to cover the case that you ask for the keys, and get them back in the result. Maybe strictly not necessary, but possibly simpler. Anyway, it doesn't seem very important to change... [Side note: one thing that *really* is problematic in real life is the lack of a depth-limiting parameter in subtree filters. For example, there is no simple generic way to check if a P-container exists w/o getting the entire subtree (depending on data model there might be cases where you can construct a clever filter).] > 2) attribute test on a content-match node > Sec. 6.2.2, para 1 has this text: > > If an element is not defined to include a > specified attribute, then it is not selected in the filter output. > > It is unclear whether the content-match test result is used > if the attribute test fails. IMO the content-match test fails, > which causes the entire sibling set to be removed. I agree. /martin From nobody Fri May 22 12:59:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E321A875C for ; Fri, 22 May 2015 12:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsmLIuHdJFS2 for ; Fri, 22 May 2015 12:59:32 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id DB6A81A7034 for ; Fri, 22 May 2015 12:59:31 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA29205; Fri, 22 May 2015 15:59:29 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t4MJxSwK081290; Fri, 22 May 2015 15:59:28 -0400 (EDT) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t4MJxRHR081289; Fri, 22 May 2015 15:59:27 -0400 (EDT) (envelope-from luchuk) Date: Fri, 22 May 2015 15:59:27 -0400 (EDT) From: Alan Luchuk Message-Id: <201505221959.t4MJxRHR081289@mainfs.snmp.com> To: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 19:59:34 -0000 Hello, I have fairly closely read draft-ietf-netconf-call-home-05. I think document could be advanced as-is. That said, I have included a few comments below. Most of the comments are stylistic or wording preferences, that can be ignored, included, or omitted as appropriate. The first three comments are more substantial. Regards, --Alan Page 5, starting in section 2, subsection 2.1, item C1: ------------------------------------------------------- The text reads: C1 The NETCONF/RESTCONF client listens for TCP connection requests from NETCONF/RESTCONF servers. The client SHOULD listen for I suggest adding the following text as the last paragraph in the Introduction, (Section 1): In this document, the term "NETCONF/RESTCONF" is used as an abbreviation in place of the text "the NETCONF or the RESTCONF". The NETCONF/RESTCONF abbreviation is not intended to require or to imply that a client or client or server must implement both the NETCONF standard and the RESTCONF standard. Page 6, section 2.1, item C5: ----------------------------- The text reads: validation data (e.g., pinning, using the entire host key or certificate as the lookup key) or via certificate path validation Perhaps delete the word "pinning"? Upon first read, I was not sure what "pinning" meant. Upon a second read, I assume that "pinning" is defined by the rest of the phrase in parenthesis. As an unrelated issue, the phrase suggests the _entire_ certificate is used as the lookup key. Is this what was intended? Page 4, section 1, last paragraph: ---------------------------------- s/to also support call home/to support call home also/ The phrase "to also support" is a split infinitive, which once upon a time was considered bad grammer. The rest of the comments are stylistic or wording preferences, that can be ignored, included, or omitted as appropriate. Page 3, Section 1, third paragraph: ----------------------------------- s/TLS, same as the RESTCONF protocol/TLS, the same as the RESTCONF protocol/ ^^^ Page 3, Section 1, fifth paragraph: ----------------------------------- s/protocol stacks, as when/protocol stacks, as/ ^^^^ Page 4, first paragraph on the page under section 1: ---------------------------------------------------- s/TCP layer; that is, in which/TCP layer; that is, which/ ^^ Page 4, second paragraph on the page under section 1: ----------------------------------------------------- I suggest splitting the first sentence into to sentences, from: For example, a network element is traditionally the TCP-server however, when calling home, the network element becomes the TCP- to: For example, a network element is traditionally the TCP-server. However, when calling home, the network element becomes the TCP- Page 5, Section 2.1, item C1: ----------------------------- The last part of thelast sentence reads: Section 5, but MAY be configured to use a non-default port. Would changing "non-default" to "non-standard" or "non-IANA-assigned" be clearer? This same comment applies to the second sentence under item S1 in Section 3.1 on Page 7. Page 6, Section 2.2, first sentence: ------------------------------------ Would changing: How to configure a NETCONF or RESTCONF client is outside the scope of to: How a NETCONF or RESTCONF client is configured is outside the scope of be a little clearer? This same comment applies to the first sentence of Section 3.1 on Page 7. From nobody Tue May 26 14:14:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B251B3183; Tue, 26 May 2015 14:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsmzlnFkjpKK; Tue, 26 May 2015 14:14:02 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CFBF21B317A; Tue, 26 May 2015 14:14:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:13:59 -0400 Message-ID: <00a101d097f8$e2847700$a78d6500$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A2_01D097D7.5B78F180" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX+KHfDvCKoPtTS9efx7CdbCb8fA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: [Netconf] I2RS interim 5/27 10:00am - 11:30am EDT (Webex) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:14:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A2_01D097D7.5B78F180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A3_01D097D7.5B78F180" ------=_NextPart_001_00A3_01D097D7.5B78F180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The I2RS interim is schedule for Wednesdsay 5/27 10:00am =E2=80=93 = 11:30am. The interim schedule opens 30 minutes early to allow speakers = to check their mike and make sure there slides are ready.=20 =20 There are two topics on the agenda:=20 =20 1) I2RS Protocol requirements with discussion on the following = drafts =20 a. = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ = (WG adoption 5/26 to 6/9/2015)=20 b. = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requiremen= ts (WG adoption 5/26 to 6/9/2015) c. = http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ( = WG LC 5/26 to 6/9/2015)=20 d. http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ = WG LC 5/26 to 6/9/2015)=20 =20 These set of requirements are intent as a group of requirements to pass = to the netmod/netconf WG on 6/10.=20 The 6/10 I2RS interim will review the discussions on the email list, and = finalize the set of documents passed to netconf/netmod for review.=20 =20 2) Announcement of I2RS Design team for FB-RIB documents=20 a. Review of draft = = draft-kini-i2rs-fb-fib-info-model-00=20 b. Review of Yang models proposed=20 i. = Generic FB-RIB-info-model=20 ii. = Rules specific to individual RIB-forwarding=20 =20 This meeting is to provide verbal discussions as a prelude to the I2RS = mail list discussions on the protocol, and to inform the WG regarding = the FB-RIB models in order to aid the WG on the protocol discussion.=20 =20 We apologize for the reminder of the meeting time, and the web-ex = meeting.=20 =20 Sue Hares and Jeff Haas=20 =20 From: I2RS Working Group [mailto:messenger@webex.com]=20 Sent: Tuesday, May 26, 2015 4:34 PM To: i2rs-chairs@tools.ietf.org Subject: WebEx meeting scheduled: I2RS interim 5/27 =20 Hi, I2RS Working Group,=20 You are the host for this WebEx meeting.=20 =20 Host key: 487042 (Use this to reclaim host privileges.)=20 =20 =20 =20 I2RS interim 5/27=20 Wednesday, May 27, 2015=20 9:30 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 646 391 150=20 Meeting password: jeff.is.wise =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 391 150 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. =20 =20 =20 Can't join the meeting? Contact = support.=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. You should inform all meeting attendees = prior to recording if you intend to record the meeting. =20 ------=_NextPart_001_00A3_01D097D7.5B78F180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The I2RS interim is schedule for Wednesdsay 5/27 10:00am =E2=80=93 = 11:30am. The interim schedule opens 30 minutes early to allow speakers = to check their mike and make sure there slides are ready. =

 

There are two topics on the agenda:

 

1)      = I2RS Protocol requirements =C2=A0with discussion on the following = drafts =C2=A0

a.       = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/=C2=A0 (WG adoption 5/26 to 6/9/2015)

b.      = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netcon= f-requirements (WG adoption 5/26 to = 6/9/2015)

c.       = http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/ ( WG LC 5/26 to 6/9/2015)

d.      = ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/=C2=A0 WG = LC 5/26 to 6/9/2015)

 =

These set = of requirements are intent as a group of requirements to pass to the = netmod/netconf WG on 6/10.

The 6/10 = I2RS interim will review the discussions on the email list, and finalize = the set of documents passed to netconf/netmod for review. =

 =

2)      = Announcemen= t of I2RS Design team for FB-RIB documents

a.       = Review of = draft draft-kin= i-i2rs-fb-fib-info-model-00 

b.      = Review of Yang models proposed =

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   i.      = Generic FB-RIB-info-model =

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp; ii.      = Rules specific to individual RIB-forwarding = =

 =

This = meeting is to provide verbal discussions as a prelude to the I2RS mail = list discussions on the protocol, and to inform the WG regarding the = FB-RIB models in order to aid the WG on the protocol discussion. =

 =

We = apologize for the reminder of the meeting time, and the web-ex meeting. =

 

Sue Hares and Jeff Haas

 

From:= = I2RS Working Group [mailto:messenger@webex.com]
Sent: = Tuesday, May 26, 2015 4:34 PM
To: = i2rs-chairs@tools.ietf.org
Subject: WebEx meeting scheduled: = I2RS interim 5/27

 

Hi, I2RS Working Group,

You are the host for this WebEx meeting. =

 

Host key: 487042 (Use this to reclaim host privileges.) =

 

 

 

I2RS interim = 5/27 =

Wednesday, May 27, 2015

9:30 am  |  Eastern Daylight Time (New York, = GMT-04:00)  |  2 hrs =

 

 

 

Join = WebEx meeting =

 

Meeting number:

646 391 150

Meeting password:

jeff.is.wise

 

 

 

Join by = phone

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

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

Access code: 646 391 150

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your = calendar.

 

 

 

Can't join the meeting? Contact support. =

 

 

 

= IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. You should inform all meeting attendees = prior to recording if you intend to record the = meeting.

 

------=_NextPart_001_00A3_01D097D7.5B78F180-- ------=_NextPart_000_00A2_01D097D7.5B78F180 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting.ics" BEGIN:VCALENDAR=0A= PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN=0A= VERSION:2.0=0A= METHOD:REQUEST=0A= BEGIN:VTIMEZONE=0A= TZID:Eastern Time=0A= BEGIN:STANDARD=0A= DTSTART:20131101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0A= TZOFFSETTO:-0500=0A= TZNAME:Standard Time=0A= END:STANDARD=0A= BEGIN:DAYLIGHT=0A= DTSTART:20130301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0A= TZOFFSETTO:-0400=0A= TZNAME:Daylight Savings Time=0A= END:DAYLIGHT=0A= END:VTIMEZONE=0A= BEGIN:VEVENT=0A= ATTENDEE;CN=3D"I2RS Working = Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE:MAILTO:i2rs-chairs@tools.ietf.= org=0A= ORGANIZER;CN=3D"webex":MAILTO:messenger@webex.com=0A= DTSTART;TZID=3D"Eastern Time":20150527T093000=0A= DTEND;TZID=3D"Eastern Time":20150527T113000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1432672422=0A= UID:ff572edf-29d8-499c-ae8b-114047c18e30=0A= DTSTAMP:20150527T133000Z=0A= DESCRIPTION:\nHost key: 487042\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm70918adad686cacc341500= c2d75e34c4\nMeeting number: 646 391 150\nMeeting password: = jeff.is.wise\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free number = (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nAccess = code: 646 391 150\n\nToll-free dialing restrictions: = \nhttp://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join = the meeting? Contact support = here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during = the session to be recorded, which may be discoverable in a legal matter. = You should inform all meeting attendees prior to recording if you intend = to record the meeting.\n=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:  
Host key: = 487042 
 
 
Join WebEx = meeting =
Meeting number: 646 391 = 150
Meeting = password:jeff.is.wise
 
 
Join by = phone 
1-877-668-4493 Call-in toll free = number (US/Canada) 
1-650-479-3208 Call-in toll number = (US/Canada) 
Access code: 646 391 150 
Toll-free calling = restrictions  


 
Can't join the = meeting? Contact support. =  
 
IMPORTANT NOTICE: Please note that this WebEx service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. You should inform = all meeting attendees prior to recording if you intend to record the = meeting.=0A= SUMMARY:I2RS interim 5/27=0A= PRIORITY:5=0A= CLASS:PUBLIC=0A= BEGIN:VALARM=0A= TRIGGER:-PT5M=0A= ACTION:DISPLAY=0A= DESCRIPTION:Reminder=0A= END:VALARM=0A= END:VEVENT=0A= END:VCALENDAR=0A= ------=_NextPart_000_00A2_01D097D7.5B78F180-- From nobody Tue May 26 14:28:25 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAE31B31F0; Tue, 26 May 2015 14:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ehjY_3dTaSy; Tue, 26 May 2015 14:28:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C3EF51B31F9; Tue, 26 May 2015 14:28:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:28:17 -0400 Message-ID: <00d801d097fa$e1c756a0$a55603e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01D097D9.5AB8C3E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX+oY2bTi4IH4qRaukXOC6nfsAwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: [Netconf] This is 2 week adoption call for draft-haas-i2rs-ephemeral-state-req (5/26 to 6/9) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:28:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D9_01D097D9.5AB8C3E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. This document is a companion to three other documents for I2RS requirements which have WG calls: 1) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ [This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 2) draft-ietf-i2rs-pub-sub-requirements-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-haas-i2rs-ephemeral-state-req (5/26 to 6/9). Jeff is the author so he will be kicking of the adoption call and responding to the IPR question (do you know of any IPR on the requirements draft). Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but it is required. ------=_NextPart_000_00D9_01D097D9.5AB8C3E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: =

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the netmod and = netconf Working

   Groups = for functionality to support the ephemeral state = requirements

   to = implement the I2RS architecture.

 

 

This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

1)      draft-haas-i2rs-netmod-netconf= -requirements-01 

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netco= nf-requirements/

 

[This draft is an early set of requirements = from which the ephemeral state and “identity, secondary-identity = and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) =

 

2)      draft-ietf-= i2rs-pub-sub-requirements-02  =

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

I2RS Status: WG LC (5/26 to 6/9) =

 

 <= /p>

3)      draft-iet= f-i2rs-traceability-02 

ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

(5/26 to 6/9) =

 

This thread is to discuss the = draft-haas-i2rs-ephemeral-state-req (5/26 to 6/9).  Jeff is the = author so he will be kicking of the adoption call and responding to the = IPR question (do you know of any IPR on the requirements draft).  =

 

Sue Hares

 

PS – = Yes – I know an IPR call on a requirements draft may seem silly, = but it is required.

 

=

 

------=_NextPart_000_00D9_01D097D9.5AB8C3E0-- From nobody Tue May 26 14:36:33 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E15B1B3202; Tue, 26 May 2015 14:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ue39Sygk4BP; Tue, 26 May 2015 14:36:28 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CC8271B3201; Tue, 26 May 2015 14:36:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:36:26 -0400 Message-ID: <00f101d097fc$05a0a030$10e1e090$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01D097DA.7E914A20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX+y7VjhtpZaQbTuuEu5xIa4QtPA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: [Netconf] draft-haas-i2rs-netmod-netconf-requirements-01 (2 week WG adoption - (5/26 to 6/9/2015) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:36:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F2_01D097DA.7E914A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week adoption call for draft-haas-i2rs-netmod-netconf-requirements-01 (5/26 to 6/9/2015). This document is a companion to three other documents for I2RS requirements which have WG calls: This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) The three other documents are: 1) Draft-haas-i2rs-ephemeral-state-reqs-00 https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. 2) draft-ietf-i2rs-pub-sub-requirements-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-haas-i2rs-netmod-netconf-requirements-01 ( (5/26 to 6/9). Jeff is the author so he will be kicking of the response to the adoption call and state if he knows of any IPR. Please note that the adoption of this draft is to show WG direction, and we expect a more detailed draft may be created for mutual authentication requirements (section 2.2) and transaction requirements. Jeff and I welcome more detailed proposals for mutual authentication requirements (section 2.2) and transaction requirements. If you are interested in working on a quick turn on a proposal, please contact me. I am working on this draft and would like co-authors. Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but it is required. ------=_NextPart_000_00F2_01D097DA.7E914A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week adoption call for = draft-haas-i2rs-netmod-netconf-requirements-01 (5/26 to 6/9/2015). This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

This draft = is an early set of requirements from which the ephemeral state and = “identity, secondary-identity and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS = Status: WG Adoption (5/26 to 6/9)

 

The three = other documents are:

 

1)      = Draft-haas-i2rs-ephemeral-state-reqs-00

 

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the netmod and = netconf Working

   Groups = for functionality to support the ephemeral state = requirements

   to = implement the I2RS architecture.

 

2)      draft-ietf-= i2rs-pub-sub-requirements-02  =

    http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

    I2RS Status: WG LC (5/26 = to 6/9)

 

 <= /p>

3)      = draft-iet= f-i2rs-traceability-02 

     ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

      (5/26 to 6/9) =

 

This thread is to discuss the = draft-haas-i2rs-netmod-netconf-requirements-01 ( (5/26 to 6/9). =  Jeff is the author so he will be kicking of the response to the = adoption call and state if he knows of any IPR.

 

Please note = that the adoption of this draft is to show WG direction, and we expect a = more detailed draft may be created for mutual authentication = requirements (section 2.2) and transaction requirements.  Jeff and = I welcome more detailed proposals for mutual authentication requirements = (section 2.2) and transaction requirements.  If you are interested = in working on a quick turn on a proposal, please contact me.  I am = working on this draft and would like co-authors.

 

Sue Hares =

 

PS – Yes – I know an IPR call on a = requirements draft may seem silly, but it is required.

 

------=_NextPart_000_00F2_01D097DA.7E914A20-- From nobody Tue May 26 14:55:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA11B3222; Tue, 26 May 2015 14:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S790X8F1Q_OI; Tue, 26 May 2015 14:54:45 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2E1B3224; Tue, 26 May 2015 14:54:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:54:31 -0400 Message-ID: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0128_01D097DD.0576C220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX/brn0dvPMo3GSuqLIt07oHEavg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: cpignata@cisco.com, netmod@ietf.org, "'Gonzalo Salgueiro \(gsalguei\)'" , 'Alia Atlas' , netconf@ietf.org Subject: [Netconf] 2 week WG LC for draft-ietf-i2rs-traceabilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:54:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0128_01D097DD.0576C220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 from (5/26 to 6/9) (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) I2RS Status: WG LC (5/26 to 6/9) Carlos, joe, and Gonzalo - please indicate whether you know of any IPR on this draft. This document is a companion to three other documents for I2RS requirements which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ [This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draf-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) This thread is to discuss WG consensus on draft-ietf-i2rs-traceability-02 . Please discuss the merits of the traceability framework described in this draft as being part of the requirements forwarded to netmod/netconf. Also discuss if this framework provides the necessary things for I2RS deployment. This draft will also be forwarded as part of the requirements to the IESG. Sue Hares ------=_NextPart_000_0128_01D097DD.0576C220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC for draft-iet= f-i2rs-traceability-02 from (5/26 to 6/9)  

(ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) =

 

I2RS Status: WG LC (5/26 to 6/9) =

 

Carlos, joe, = and Gonzalo – please indicate whether you know of any IPR on this = draft.

 

 

This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

1)      = This begins a 2 week adoption call for = draft-haas-i2rs-ephemeral-state-req:

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the = netmod and netconf Working

   Groups for functionality to = support the ephemeral state requirements

   to implement the I2RS = architecture.

 

Status: WG adoption call (5/26 to 6/9) =

 

2)      draft-haas-i2rs-netmod-netconf= -requirements-01 

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netco= nf-requirements/

 

[This draft is an early set of requirements = from which the ephemeral state and “identity, secondary-identity = and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) =

 

3)      = draf-ietf-i2rs-pub-sub-requirements-02. =

 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

I2RS Status: WG LC (5/26 to 6/9) =

 

 

This thread = is to discuss WG consensus on  draft-iet= f-i2rs-traceability-02 .  Please discuss the merits of = the traceability framework described in this draft as being part of the = requirements forwarded to netmod/netconf.   Also discuss if = this framework provides the necessary things for I2RS deployment. =

 

This draft will also be forwarded as part of the = requirements to the IESG.

 

Sue Hares =

 

 

 

------=_NextPart_000_0128_01D097DD.0576C220-- From nobody Tue May 26 15:07:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE32A1B3230; Tue, 26 May 2015 15:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzFgHX_vgVtM; Tue, 26 May 2015 15:07:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12DA1B322C; Tue, 26 May 2015 15:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2919; q=dns/txt; s=iport; t=1432678066; x=1433887666; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NYVVt1CS83B6ht/AG80FwiJz6aRcLyjhwLXB862daBg=; b=A3l1dcM88iFSJq+m5KmG4CR4F6AQ2p3UBVGwQnRLllVlZiy+nzhpZ33k ke5wR5oYPlE08fLpJwOdDVF8EsmnGT8SqKlX1Z5XHJ502UWqLilvI/Sps b+dQfWrbNgWdw6oaESli3jgQDok0nmDmNZddEPjd59gyQretCCt94yKUv k=; X-IronPort-AV: E=Sophos;i="5.13,501,1427760000"; d="scan'208";a="422765105" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 26 May 2015 22:07:45 +0000 Received: from [10.117.46.173] (rtp-jclarke-89112.cisco.com [10.117.46.173]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4QM7hla013958; Tue, 26 May 2015 22:07:43 GMT Message-ID: <5564EEAF.3040901@cisco.com> Date: Tue, 26 May 2015 18:07:43 -0400 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" , Susan Hares References: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> In-Reply-To: <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "Carlos Pignataro \(cpignata\)" , Alia Atlas , "netconf@ietf.org" Subject: Re: [Netconf] 2 week WG LC for draft-ietf-i2rs-traceabilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 22:07:46 -0000 On 5/26/15 6:05 PM, Gonzalo Salgueiro (gsalguei) wrote: > I have no IPR to declare related to this draft, nor do I know of any. No, no IPR. Joe > > Regards, > > Gonzalo > > > > On May 26, 2015, at 5:54 PM, Susan Hares > wrote: > >> This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 >> from >> (5/26 to 6/9) >> >> (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) >> >> I2RS Status: WG LC (5/26 to 6/9) >> >> Carlos, joe, and Gonzalo – please indicate whether you know of any IPR >> on this draft. >> >> This document is a companion to three other documents for I2RS >> requirements which have WG calls: >> >> 1)This begins a 2 week adoption call for >> draft-haas-i2rs-ephemeral-state-req: >> >> https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ >> >> This document covers requests to the netmod and netconf Working >> >> Groups for functionality to support the ephemeral state requirements >> >> to implement the I2RS architecture. >> >> Status: WG adoption call (5/26 to 6/9) >> >> 2)draft-haas-i2rs-netmod-netconf-requirements-01 >> >> >> http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ >> >> [This draft is an early set of requirements from which the ephemeral >> state and “identity, secondary-identity and priority” were pulled into >> draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription >> were pulled into the draft-ietf-i2rs-pub-sub-requirments. The >> traceability had been separated before >> draft-haas-i2rs-nemod-netconf-requirements was published. This draft >> remains the only source for mutual authentication requirements >> (section 2.2), transaction requirements, and the history of the >> discussion. This draft is being requested to be adopted as a general >> roadmap for the I2RS WG. In the future, the I2RS WG will accept more >> detailed specification on the mutual authentication or the transaction >> protocol. >> >> I2RS Status: WG Adoption (5/26 to 6/9) >> >> 3)draf-ietf-i2rs-pub-sub-requirements-02. >> >> http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ >> >> I2RS Status: WG LC (5/26 to 6/9) >> >> This thread is to discuss WG consensus on >> draft-ietf-i2rs-traceability-02 >> . >> Please discuss the merits of the traceability framework described in >> this draft as being part of the requirements forwarded to >> netmod/netconf. Also discuss if this framework provides the >> necessary things for I2RS deployment. >> >> This draft will also be forwarded as part of the requirements to the >> IESG. >> >> Sue Hares >> From nobody Tue May 26 17:20:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53AD1ACE38; Tue, 26 May 2015 17:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMpHJ68Vxj5l; Tue, 26 May 2015 17:20:36 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 824A81ACE39; Tue, 26 May 2015 17:20:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 20:20:34 -0400 Message-ID: <017a01d09812$f31d4780$d957d680$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017B_01D097F1.6C0EB4C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX/SqdWbWgG8/OQamGAg9/X0In5w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (5/26 to 6/9) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 00:20:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017B_01D097F1.6C0EB4C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC on draft-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) Eric, Alexander, Gonzalez - please state whether you know of any IPR related to the draft. This document is a companion to three other documents for I2RS requirements which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ [This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-i2rs-pub-sub-requirements-02 and forwarding to the netmod/netconf and IESG as requirement for I2RS. Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but it is required. ------=_NextPart_000_017B_01D097F1.6C0EB4C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC on draft-ietf-i2rs-pub-sub-requirements-02. =

 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

I2RS Status: WG LC (5/26 to 6/9) =

 

Eric, = Alexander, Gonzalez – please state whether you know of any IPR = related to the draft.  

 

This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

1)      = This begins a 2 week adoption call for = draft-haas-i2rs-ephemeral-state-req:

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the = netmod and netconf Working

   Groups for functionality to = support the ephemeral state requirements

   to implement the I2RS = architecture.

 

Status: WG adoption call (5/26 to 6/9) =

 

2)      draft-haas-i2rs-netmod-netconf= -requirements-01 

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netco= nf-requirements/

 

[This draft is an early set of requirements = from which the ephemeral state and “identity, secondary-identity = and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) =

 

3)      = draft-iet= f-i2rs-traceability-02 

ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

(5/26 to 6/9) =

 

This thread is to discuss the = draft-i2rs-pub-sub-requirements-02 and forwarding to the netmod/netconf = and IESG as requirement for I2RS.  

 

Sue Hares =

 

PS – Yes – I know an IPR call on a = requirements draft may seem silly, but it is required.

 

 

 

 

------=_NextPart_000_017B_01D097F1.6C0EB4C0-- From nobody Tue May 26 22:42:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB591A00B2; Tue, 26 May 2015 22:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIZaNOOR15EN; Tue, 26 May 2015 22:41:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FD01A009B; Tue, 26 May 2015 22:41:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3CEC910C8; Wed, 27 May 2015 07:41:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QZvfogcwvDOp; Wed, 27 May 2015 07:41:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 May 2015 07:41:53 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92D0C2002B; Wed, 27 May 2015 07:41:53 +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 U4tkOcVBdnzZ; Wed, 27 May 2015 07:41:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96FC320013; Wed, 27 May 2015 07:41:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 368163384F67; Wed, 27 May 2015 07:41:48 +0200 (CEST) Date: Wed, 27 May 2015 07:41:48 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150527054148.GA6258@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org References: <00a101d097f8$e2847700$a78d6500$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <00a101d097f8$e2847700$a78d6500$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: i2rs@ietf.org, 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] I2RS interim 5/27 10:00am - 11:30am EDT (Webex) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 05:41:58 -0000 On Tue, May 26, 2015 at 05:13:59PM -0400, Susan Hares wrote: > The I2RS interim is schedule for Wednesdsay 5/27 10:00am – 11:30am. The interim schedule opens 30 minutes early to allow speakers to check their mike and make sure there slides are ready. > > > > There are two topics on the agenda: > > > > 1) I2RS Protocol requirements with discussion on the following drafts > > a. https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ (WG adoption 5/26 to 6/9/2015) > > b. http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements (WG adoption 5/26 to 6/9/2015) > I can't make it to this meeting. My suggestion is to merge the above two I-Ds into one I-D. There is already overlap. It also seems that a. goes quite a bit into solution space, so calling it a requirements document may be a bit of a stretch. (But that said, we need to start talking about solutions since we already have a document full of requirements.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed May 27 06:55:18 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE4A1ACF55; Wed, 27 May 2015 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEDaoyKcrO7n; Wed, 27 May 2015 06:55:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 54FA31A1A86; Wed, 27 May 2015 06:55:14 -0700 (PDT) Received: from [192.168.1.70] (99-59-193-146.lightspeed.livnmi.sbcglobal.net [99.59.193.146]) by slice.pfrc.org (Postfix) with ESMTPSA id 13B101E30A; Wed, 27 May 2015 09:55:52 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jeffrey Haas In-Reply-To: <20150527054148.GA6258@elstar.local> Date: Wed, 27 May 2015 09:55:12 -0400 Message-Id: <75138D77-1D2C-4E2C-9976-4CC119E079C7@pfrc.org> References: <00a101d097f8$e2847700$a78d6500$@ndzh.com> <20150527054148.GA6258@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netmod@ietf.org, i2rs@ietf.org, Alia Atlas , netconf@ietf.org Subject: Re: [Netconf] [i2rs] [netmod] I2RS interim 5/27 10:00am - 11:30am EDT (Webex) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 13:55:17 -0000 --Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 27, 2015, at 1:41 AM, Juergen Schoenwaelder = wrote: >=20 > On Tue, May 26, 2015 at 05:13:59PM -0400, Susan Hares wrote: >> The I2RS interim is schedule for Wednesdsay 5/27 10:00am =E2=80=93 = 11:30am. The interim schedule opens 30 minutes early to allow speakers = to check their mike and make sure there slides are ready.=20 >>=20 >>=20 >>=20 >> There are two topics on the agenda:=20 >>=20 >>=20 >>=20 >> 1) I2RS Protocol requirements with discussion on the following = drafts =20 >>=20 >> a. = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ = (WG adoption 5/26 to 6/9/2015)=20 >>=20 >> b. = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirement= s (WG adoption 5/26 to 6/9/2015) >>=20 >=20 > I can't make it to this meeting. My suggestion is to merge the above > two I-Ds into one I-D. There is already overlap. I believe I=E2=80=99d prefer to not adopt the netmod-netconf draft. Its = goal, as explained during the last netconf WG session that I presented = it in, is to simply use it as the placeholder =E2=80=9CTODO=E2=80=9D = list for the actual drafts covering the work. However, there was strong = pressure to have adopted WG items to cover the contents. The state = draft is another piece of that. I believe this leaves authentication requirements as the only meaningful = content. A last draft covering that may perhaps be spun out or not as = the WG desires. After that, the netmod-netconf requirements draft can = die. > It also seems that > a. goes quite a bit into solution space, so calling it a requirements > document may be a bit of a stretch. (But that said, we need to start > talking about solutions since we already have a document full of > requirements.) The actual requirements have been stalled since before the NYC interim: = We need ephemeral state. The implications of any given solution space = are too important to draft requirements in the absence of some = understanding of the likely solution. I=E2=80=99m happy to rename the draft something that doesn=E2=80=99t = contain the word =E2=80=9Crequirements=E2=80=9D if you have a better = suggestion. =E2=80=94 Jeff --Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 27, 2015, at 1:41 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Tue, May 26, 2015 at 05:13:59PM -0400, Susan = Hares wrote:
The I2RS interim is schedule for Wednesdsay 5/27 = 10:00am =E2=80=93 11:30am. The interim schedule opens 30 minutes early = to allow speakers to check their mike and make sure there slides are = ready. 



There are two = topics on the agenda: 



1) =      I2RS Protocol requirements  with = discussion on the following drafts  

a. =       https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-stat= e-reqs/  (WG adoption 5/26 to 6/9/2015) 

b.      http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-= requirements (WG adoption 5/26 to 6/9/2015)


I can't make it to this = meeting. My suggestion is to merge the above
two I-Ds into one I-D. There is already = overlap.

I believe = I=E2=80=99d prefer to not adopt the netmod-netconf draft.  Its = goal, as explained during the last netconf WG session that I presented = it in, is to simply use it as the placeholder =E2=80=9CTODO=E2=80=9D = list for the actual drafts covering the work.  However, there was = strong pressure to have adopted WG items to cover the contents. =  The state draft is another piece of that.

I believe this leaves authentication requirements = as the only meaningful content.  A last draft covering that may = perhaps be spun out or not as the WG desires.  After that, the = netmod-netconf requirements draft can die.

It also seems that
a. goes quite a bit into solution space, so = calling it a requirements
document may be a bit of a = stretch. (But that said, we need to start
talking about solutions since we already have a = document full of
requirements.)

The actual = requirements have been stalled since before the NYC interim: We need = ephemeral state.  The implications of any given solution space are = too important to draft requirements in the absence of some understanding = of the likely solution.

I=E2=80=99m = happy to rename the draft something that doesn=E2=80=99t contain the = word =E2=80=9Crequirements=E2=80=9D if you have a better = suggestion.

=E2=80=94 = Jeff

= --Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8-- From nobody Wed May 27 07:09:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B81B2ACE; Wed, 27 May 2015 07:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxNcYP8aLZ5h; Wed, 27 May 2015 07:09:45 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FE01B2ABE; Wed, 27 May 2015 07:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14845; q=dns/txt; s=iport; t=1432735787; x=1433945387; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pzx2FcQxFTH7FyWj9H8vi4XEV2jn9Zk0G98cU/BJqmk=; b=eebS61YYZdQv4f8TBrousSAfMx/Lz4Ok3CWigOT0GyONQ4KMX3Gva54C ppG953rIu2ps3A5WiK7ujDTPycZEfbysOLTb/7a4Zw4BqJQhsDaFs88UW jVIe/ZSBO6BXLm/4dJGO9DjiPllO1T577jtUtpsE85YksZt/7aUklcMoG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1BADcz2VV/5FdJa1TCYJFS1ReBrMljg0qCYFbhXUCgTw4FAEBAQEBAQGBCoQiAQEBBB0QTBACAQgOAwEDAQELAxoHMhQDBggBAQQBDQUIiCUN0GYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqEKSstBAYBgxeBFgWTCIQ1hluBKD6DM5IVI4I7gT1vgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,506,1427760000"; d="scan'208,217";a="153774712" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 27 May 2015 14:09:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4RE9iwu000358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 14:09:44 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 27 May 2015 09:09:44 -0500 From: "Eric Voit (evoit)" To: Susan Hares , "i2rs@ietf.org" Thread-Topic: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (5/26 to 6/9) Thread-Index: AdCX/SqdWbWgG8/OQamGAg9/X0In5wAiVB1Q Date: Wed, 27 May 2015 14:09:43 +0000 Message-ID: References: <017a01d09812$f31d4780$d957d680$@ndzh.com> In-Reply-To: <017a01d09812$f31d4780$d957d680$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.118.56.229] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (5/26 to 6/9) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 14:09:53 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We know of no IPR related to draft-ietf-i2rs-pub-sub-requirements. Eric From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, May 26, 2015 8:21 PM To: i2rs@ietf.org Cc: netconf@ietf.org; netmod@ietf.org Subject: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (= 5/26 to 6/9) This begins a 2 week WG LC on draft-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) Eric, Alexander, Gonzalez - please state whether you know of any IPR relate= d to the draft. This document is a companion to three other documents for I2RS requirements= which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-st= ate-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements= / [This draft is an early set of requirements from which the ephemeral state = and "identity, secondary-identity and priority" were pulled into draft-haas= -i2rs-ephemeral-state-reqs. The notification-subscription were pulled int= o the draft-ietf-i2rs-pub-sub-requirments. The traceability had been sepa= rated before draft-haas-i2rs-nemod-netconf-requirements was published. This= draft remains the only source for mutual authentication requirements (sect= ion 2.2), transaction requirements, and the history of the discussion. Th= is draft is being requested to be adopted as a general roadmap for the I2RS= WG. In the future, the I2RS WG will accept more detailed specification on = the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-i2rs-pub-sub-requirements-02 and forwar= ding to the netmod/netconf and IESG as requirement for I2RS. Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but i= t is required. --_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We know of no IPR rela= ted to draft-ietf-i2rs-pub-sub-requirements.

 

Eric=

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, May 26, 2015 8:21 PM
To: i2rs@ietf.org
Cc: netconf@ietf.org; netmod@ietf.org
Subject: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requremen= ts-02 (5/26 to 6/9)

 

This begins a 2 week WG L= C on draft-ietf-i2rs-pub-sub-requirements-02.

 

http://d= atatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/

 

I2RS Status: WG LC (5/26 to 6= /9)

 

Eric, Alexander, Gonzalez= – please state whether you know of any IPR related to the draft. &nb= sp;

 

This document is a compan= ion to three other documents for I2RS requirements which have WG calls:

 

1)      This begins a 2 week adoption call for draft-haas-i= 2rs-ephemeral-state-req:

https://d= atatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/

 =

  This docum= ent covers requests to the netmod and netconf Working

   Grou= ps for functionality to support the ephemeral state requirements=

   to i= mplement the I2RS architecture.

 =

Status: WG adopti= on call (5/26 to 6/9)

 =

2)&n= bsp;     draft-haas-i2rs-netmod-netconf-requirements-01 

htt= p://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/

 =

[This draft is an= early set of requirements from which the ephemeral state and “identi= ty, secondary-identity and priority” were pulled into draft-haas-i2rs= -ephemeral-state-reqs.  The  notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments.   The = traceability had been separated before draft-haas-i2rs-nemod-netconf-requir= ements was published. This draft remains the only source for mutual authent= ication requirements (section 2.2), transaction requirements, and the history of the discussion.   This draft is= being requested to be adopted as a general roadmap for the I2RS WG. In the= future, the I2RS WG will accept more detailed specification on the mutual = authentication or the transaction protocol.

 =

I2RS Status: WG A= doption (5/26 to 6/9)

 

&n= bsp;

3)      draft-ietf-i2rs-traceability-02&nb= sp;

http://d= atatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

(5/26 to= 6/9)

 

This thread is to discuss= the draft-i2rs-pub-sub-requirements-02 and forwarding to the netmod/netcon= f and IESG as requirement for I2RS.  

 

Sue Hares

 

PS – Yes – I = know an IPR call on a requirements draft may seem silly, but it is required= .

 

 

 

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_-- From nobody Wed May 27 09:45:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526861B2D97; Wed, 27 May 2015 08:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv8TfbdOzErP; Wed, 27 May 2015 08:51:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADBA1B2E1E; Wed, 27 May 2015 08:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20039; q=dns/txt; s=iport; t=1432741892; x=1433951492; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rLCPMgPZvew6SBdfOCErBo+MdMce9Ag+wC5i0d/9GKI=; b=MBd+qYRwsmtsyg9BpCj2yu1eOsN1uB9vkavnsG42CaaZSMuRDukxPRvI LbUm025hEPTNQWZ3Aplg9HBXXH+4q+gxP4qhb7NicFKDAiBj3eBKjEdan OAGqXvmEFoXu+gBJ3X7POZs9ny6eU+E1qlA/UZEqZT+IPBzgkEyNiuGE7 o=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BhBgCT5mVV/5xdJa1TCYJFS1RRDQazJo1RPIIOhXUCgT1MAQEBAQEBgQuEIgEBAQMBHVwFCwIBCBIGDRoHMhQDDgIEDgUOiBcIDdExAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s6hClYBAeDF4EWBZBMgjyCEoFDYIZaAYEoPoMzkhUjg3hvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,506,1427760000"; d="asc'?scan'208,217";a="423104413" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 27 May 2015 15:51:31 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4RFpVWC022588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 15:51:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 27 May 2015 10:51:31 -0500 From: "Carlos Pignataro (cpignata)" To: "Gonzalo Salgueiro (gsalguei)" Thread-Topic: 2 week WG LC for draft-ietf-i2rs-traceabilty Thread-Index: AQHQmJT/G84nv2mRhUmMuFoWysqLBQ== Date: Wed, 27 May 2015 15:51:30 +0000 Message-ID: References: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> In-Reply-To: <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.90] Content-Type: multipart/signed; boundary="Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 27 May 2015 09:45:18 -0700 Cc: "i2rs@ietf.org" , "netmod@ietf.org" , Alia Atlas , "netconf@ietf.org" Subject: Re: [Netconf] 2 week WG LC for draft-ietf-i2rs-traceabilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 15:51:39 -0000 --Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C Content-Type: multipart/alternative; boundary="Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526" --Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I do not know of any IPR relating to draft-ietf-i2rs-traceability-02. Thanks! =97 Carlos. > On May 26, 2015, at 6:05 PM, Gonzalo Salgueiro (gsalguei) = wrote: >=20 > I have no IPR to declare related to this draft, nor do I know of any. >=20 > Regards, >=20 > Gonzalo >=20 >=20 >=20 > On May 26, 2015, at 5:54 PM, Susan Hares > wrote: >=20 >> This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 = from = (5/26 to 6/9) >> (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ = ) >>=20 >> I2RS Status: WG LC (5/26 to 6/9) >>=20 >> Carlos, joe, and Gonzalo =96 please indicate whether you know of any = IPR on this draft. >>=20 >>=20 >> This document is a companion to three other documents for I2RS = requirements which have WG calls: >>=20 >> 1) This begins a 2 week adoption call for = draft-haas-i2rs-ephemeral-state-req: >> = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ = >>=20 >> This document covers requests to the netmod and netconf Working >> Groups for functionality to support the ephemeral state = requirements >> to implement the I2RS architecture. >>=20 >> Status: WG adoption call (5/26 to 6/9) >>=20 >> 2) draft-haas-i2rs-netmod-netconf-requirements-01 = >> = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirement= s/ = >>=20 >> [This draft is an early set of requirements from which the ephemeral = state and =93identity, secondary-identity and priority=94 were pulled = into draft-haas-i2rs-ephemeral-state-reqs. The = notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments. The traceability had been = separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion. This draft is being requested to be adopted as a = general roadmap for the I2RS WG. In the future, the I2RS WG will accept = more detailed specification on the mutual authentication or the = transaction protocol. >>=20 >> I2RS Status: WG Adoption (5/26 to 6/9) >>=20 >> 3) draf-ietf-i2rs-pub-sub-requirements-02. >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ = >>=20 >> I2RS Status: WG LC (5/26 to 6/9) >>=20 >>=20 >> This thread is to discuss WG consensus on = draft-ietf-i2rs-traceability-02 = . = Please discuss the merits of the traceability framework described in = this draft as being part of the requirements forwarded to = netmod/netconf. Also discuss if this framework provides the necessary = things for I2RS deployment. >>=20 >> This draft will also be forwarded as part of the requirements to the = IESG. >>=20 >> Sue Hares --Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I do not know of any IPR relating = to draft-ietf-i2rs-traceability-02.

Thanks!

=97 Carlos.

On May 26, 2015, at 6:05 PM, Gonzalo Salgueiro (gsalguei) = <gsalguei@cisco.com> wrote:

I have no IPR to = declare related to this draft, nor do I know of any.

Regards,

Gonzalo



On May 26, = 2015, at 5:54 PM, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 from (5/26 to 6/9)  
(http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/)
I2RS Status: WG LC (5/26 to 6/9)
 
This document is a companion to three = other documents for I2RS requirements which have WG calls:
 
1)      This begins a = 2 week adoption call for draft-haas-i2rs-ephemeral-state-req:
https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-stat= e-reqs/
 
  This document covers requests to the netmod and = netconf Working
   Groups for functionality to support the = ephemeral state requirements
   to implement the I2RS = architecture.
 
Status: WG adoption call (5/26 to 6/9) 
 
2)      draft-haas-i2rs-netmod-netconf-requirements-01 
http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-= requirements/
 
[This draft is an early set of requirements from which the = ephemeral state and =93identity, secondary-identity and priority=94 were = pulled into draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.
 
I2RS Status: WG Adoption (5/26 to = 6/9) 
 
3)      draf-ietf-i2rs-= pub-sub-requirements-02. 
 
 
I2RS Status: WG LC (5/26 = to 6/9)
 
 
This thread is to discuss WG consensus = on  draft-ietf-i2rs-traceability-02 .  Please discuss the = merits of the traceability framework described in this draft as being = part of the requirements forwarded to netmod/netconf.   Also = discuss if this framework provides the necessary things for I2RS = deployment.
 
This draft will also be forwarded as part of the requirements = to the IESG.
 
Sue Hares 

= --Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526-- --Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZegBAAoJEIXgpQGOZny9SaEP/0jBga0U+oiZlSm7K0jQ+NUa 1r49iW03CZP3ormv62G3W15I4YWPxqfHgt1XpgY+Fu9iEKldXTWAgFV03JtngY9M RFrkaM0hwlxDHKT+tHvpew81T7dBjQ+QL4ptUWFdFyUDCu8P5zWx0C0hL2yB9oUv +SQkptA4hCXFcM3pQXs2+Jvphgakle9XwOqXNn0CjWZ71J3BW0dkT5PmyNp1okf+ yE6/HchAxqlGvLCCoHEmpHmdn6JU77yGu/EM7I49xlWOnH/Mc3JDTlmIKUyq5Gjy /w+7OOaei7iYPMFL1vpIz00/OcCTkfBogk8s2csy/KwKUj85DnqkY+oZ3DcFH73+ 2itlWghr7+XuSg2BhZoA7IEGM9j/SeWOitqvgAUO41mc4nLRDjAN9w9RNJMN6eZP wJoxjS1klwLIZZncI9gQBvtcXE9yWZLy/QcgiglP9B6EBAWjlQwO+kYj6oo5M1Xs A8vgHksBa1DZ4M8k1rqGnaeErnRlmWA+aGBVCjhazXLWqbCzGywH3IIPGAjn2Fax RqxGSy+LZFMP0w2BrNV3cF2CTsm5pDEHuC/9BgNVZSsJJxYnXI1IAjg4okADoOyC e31hS+VLGssah/Qmbd4zvWaC2VYRvvymh7js2kxxPsINRy1XWxjlmxIi0dZN2irO Q5/u5Q23qKRpYMrO1mf9 =j1Kw -----END PGP SIGNATURE----- --Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C-- From nobody Wed May 27 18:20:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8C21B2B16 for ; Wed, 27 May 2015 18:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ynoW6jsC0Gn for ; Wed, 27 May 2015 18:20:26 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350E11ABD8F for ; Wed, 27 May 2015 18:20:26 -0700 (PDT) Received: by pdbki1 with SMTP id ki1so29507990pdb.1 for ; Wed, 27 May 2015 18:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=dSc/XIKJyDshEFqa6ghnvIN2fDHA1y2DJIXtT3JRFdo=; b=vp7twiY6iqGstpJI807ET2dArjP+MjmsL3iE7p9PPbfZKljo1ZeNWF1/o1AaWTZYs+ xaR6PI2zHqMIGcku59ekVZCe5TgslMU8ODqs7/VfkF5hQhJRwhWXd2xhZznbyQSoZkUe 0JhXsTWDva4ZK0xQiqi6DhtGYN9+RH6HP8iql5TpHvPxVjMkehMy3CfGcRGwCTmmPr+F RHAL9FOL4cfpe0jA0EVQwTEr8jKoMMLq+e5zbPb3gKYtZ0SRnjHkJZ1PLUdjbS+BlLLy CKgilyn4JdWg0J9sit33xmIClV2oA+vh968yAOvY87pURhManD4bko6egEctfAAFMbth nm+g== X-Received: by 10.70.47.68 with SMTP id b4mr430438pdn.33.1432776025927; Wed, 27 May 2015 18:20:25 -0700 (PDT) Received: from ?IPv6:2001:420:290:1266:8188:3b9c:b5d1:be1b? ([2001:420:290:1266:8188:3b9c:b5d1:be1b]) by mx.google.com with ESMTPSA id ol3sm394550pbb.70.2015.05.27.18.20.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 May 2015 18:20:25 -0700 (PDT) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <899EB8CD-973A-484E-BFE5-C9FBA7AE81C6@gmail.com> Date: Wed, 27 May 2015 18:20:46 -0700 To: netconf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Netconf] Change in affliation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 01:20:27 -0000 I know most of the work or contributions we make to IETF are in the form = of individual contribution. But in the interest of full disclosure, I = wanted to let everyone know that I have moved jobs, and I am now work = for Cisco. Cheers. Mahesh Jethanandani Co-chair, NETCONF WG mjethanandani@gmail.com From nobody Fri May 29 16:49:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C031A916D; Fri, 29 May 2015 16:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4ADH6BgCvdy; Fri, 29 May 2015 16:49:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C331A9138; Fri, 29 May 2015 16:49:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529234934.20033.71313.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 16:49:34 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 23:49:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-06.txt Pages : 13 Date : 2015-05-29 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 29 17:02:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6BB1A90B3 for ; Fri, 29 May 2015 17:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tDkp-sIEI1u for ; Fri, 29 May 2015 17:02:25 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9CC1A92DE for ; Fri, 29 May 2015 17:02:25 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.172.22; Sat, 30 May 2015 00:02:23 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Sat, 30 May 2015 00:02:23 +0000 From: Kent Watsen To: Alan Luchuk , "netconf@ietf.org" Thread-Topic: draft-ietf-netconf-call-home-05.txt Thread-Index: AQHQlMnODg1iNSV/nEqfYnzAyUNFnZ2R9UyA Date: Sat, 30 May 2015 00:02:22 +0000 Message-ID: References: <201505221959.t4MJxRHR081289@mainfs.snmp.com> In-Reply-To: <201505221959.t4MJxRHR081289@mainfs.snmp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0592A9FDE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(43784003)(199003)(189002)(51704005)(5001830100001)(83506001)(36756003)(5001860100001)(46102003)(81156007)(4001540100001)(4001350100001)(97736004)(5001770100001)(77156002)(92566002)(122556002)(105586002)(64706001)(62966003)(2656002)(2900100001)(87936001)(2950100001)(106356001)(102836002)(15975445007)(54356999)(50986999)(76176999)(19580395003)(68736005)(2501003)(5002640100001)(5001960100002)(107886002)(230783001)(86362001)(99286002)(101416001)(40100003)(189998001)(106116001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2015 00:02:23.0115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 00:02:27 -0000 Hi Alan, Thanks again for another great review. Below are my responses to your comments. I was hoping to receive more comments before posting an updated draft, but went ahead and posted -06 just now to reflect this update. Regards, Kent >Page 5, starting in section 2, subsection 2.1, item C1: >------------------------------------------------------- > >The text reads: > > C1 The NETCONF/RESTCONF client listens for TCP connection requests > from NETCONF/RESTCONF servers. The client SHOULD listen for > > >I suggest adding the following text as the last paragraph in the >Introduction, (Section 1): > > In this document, the term "NETCONF/RESTCONF" is used as an > abbreviation in place of the text "the NETCONF or the RESTCONF". > The NETCONF/RESTCONF abbreviation is not intended to require or > to imply that a client or client or server must implement both > the NETCONF standard and the RESTCONF standard. Done! - I added a section called "The NETCONF/RESTCONF Convention" >Page 6, section 2.1, item C5: >----------------------------- > >The text reads: > > validation data (e.g., pinning, using the entire host key or > certificate as the lookup key) or via certificate path validation > >Perhaps delete the word "pinning"? > >Upon first read, I was not sure what "pinning" meant. Upon a second read, >I assume that "pinning" is defined by the rest of the phrase in >parenthesis. I addressed this specific issue by changing the wording to "...to a previously trusted or 'pinned' value". So it becomes self-defining. Is this is acceptable? >As an unrelated issue, the phrase suggests the _entire_ certificate is >used=20 >as the lookup key. Is this what was intended? Yes, but looking at it more carefully, I felt that the entire bullet point wasn't clear enough and hence rewrote that section. Please see the diff for details:=20 https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-call-home-06.txt >Page 4, section 1, last paragraph: >---------------------------------- > >s/to also support call home/to support call home also/ Suggestion incorporated >The rest of the comments are stylistic or wording preferences, that can >be ignored, included, or omitted as appropriate. > > >Page 3, Section 1, third paragraph: >----------------------------------- > >s/TLS, same as the RESTCONF protocol/TLS, the same as the RESTCONF >protocol/ > ^^^ Suggestion incorporated >Page 3, Section 1, fifth paragraph: >----------------------------------- > >s/protocol stacks, as when/protocol stacks, as/ > ^^^^ Suggestion incorporated >Page 4, first paragraph on the page under section 1: >---------------------------------------------------- > >s/TCP layer; that is, in which/TCP layer; that is, which/ > ^^ Suggestion incorporated >Page 4, second paragraph on the page under section 1: >----------------------------------------------------- > >I suggest splitting the first sentence into to sentences, from: > > For example, a network element is traditionally the TCP-server > however, when calling home, the network element becomes the TCP- > >to: > > For example, a network element is traditionally the TCP-server. > However, when calling home, the network element becomes the TCP- Suggestion incorporated >Page 5, Section 2.1, item C1: >----------------------------- > >The last part of thelast sentence reads: > > Section 5, but MAY be configured to use a non-default port. > >Would changing "non-default" to "non-standard" or "non-IANA-assigned" >be clearer? > >This same comment applies to the second sentence under item S1 in >Section 3.1 on Page 7. Yes. I changed it to "non-standard" in both locations. >Page 6, Section 2.2, first sentence: >------------------------------------ > >Would changing: > > How to configure a NETCONF or RESTCONF client is outside the scope of > >to: > > How a NETCONF or RESTCONF client is configured is outside the scope of > >be a little clearer? > >This same comment applies to the first sentence of Section 3.1 on Page 7. Yes, I think so. I incorporated your suggestion in both locations. Thanks again, Kent From nobody Sun May 31 23:51:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092281A89F9 for ; Sun, 31 May 2015 23:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9gRpAcbC3a8 for ; Sun, 31 May 2015 23:51:35 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD3C1A89F0 for ; Sun, 31 May 2015 23:51:34 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-73-556c00f1870d Received: from ESGSCHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.E3.17665.2F00C655; Mon, 1 Jun 2015 08:51:30 +0200 (CEST) Received: from ESGSCMB103.ericsson.se ([169.254.3.225]) by ESGSCHC002.ericsson.se ([146.11.116.71]) with mapi id 14.03.0210.002; Mon, 1 Jun 2015 14:51:28 +0800 From: Mandy Liu To: "andy@netconfcentral.org" Thread-Topic: How to augment RFC6470 to supply detail configuration change information Thread-Index: AdCcN15yUJGf8sjGSmOLzB5x9r0Sxw== Date: Mon, 1 Jun 2015 06:51:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.128] Content-Type: multipart/alternative; boundary="_000_D970584466921040BD10823F192C30B9382B00EDESGSCMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvre4nhpxQg6+PzS2e7ZnEYjF1021W ByaPJUt+Mnl8vLuZJYApissmJTUnsyy1SN8ugStj/voFbAX71Sr2XpjE3MD4V6GLkYNDQsBE YuVJgy5GTiBTTOLCvfVsXYxcHEICRxklVl3pZoVwFjNKNP5bwAhSxSagIfH41SR2EFtEwFyi rb2DGaSIWWAro8SuJxtZQBLCAsESMzq3MYNsEBGIkDj/KRWiXk9iQecJsF4WARWJ9v7HzCA2 r4CvxJVpi9lAbEagK76fWsMEYjMLiEvcejKfCeI6AYkle84zQ9iiEi8f/2OFsJUkGl9tg6rP l5i98jsLxExBiZMzn7BMYBSehWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG 9lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgfFzcMtv3R2Mq187HmIU4GBU4uFduCc7VIg1 say4MvcQozQHi5I4r1dXSKiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRoOig8uXVoi3bs39 PV30t6rmTQa9ndoMdQy/D5kc38x1xSGMc5vJi3eH9h3g+ZSdvC7l3oxTFx78MywTNT2hxC9/ Kv1BdZgC21K20yK3jhvo/dGoX9eVcGvluUjW8EeL177hmBf733Ofo67uhDIBNn/DNxxSu1n5 byUkCsy7tk8hZvXnmqiGdCWW4oxEQy3mouJEAFiiJxqAAgAA Archived-At: Cc: Kai Lin , Robert Ottinger , "netconf@ietf.org" , Athanasios Kyparlis Subject: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 06:51:37 -0000 --_000_D970584466921040BD10823F192C30B9382B00EDESGSCMB103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy and all, For configuration change notification in RFC6470, it only provides "what is= changed" via "target" to network management. It doesn't have a field be us= ed to provide the detail configuration change information about "the config= uration is changed to what". I want to ask for your suggestion about how to= augment RFC6470 to provide "the configuration is changed to what ". I am considering to add something like "content" for "target", which is use= d to contain the detail information about the configuration changes. But th= e big question currently is for the "target" node, it may be a container, a= list, a leaf or a leaf-reference, etc. It could be any node of the tree. S= o we need to find a common format for the "content" to accommodate differen= t types of "target". what I can imagine is anyxml could be used. But seems = it is not a good choice. Because based on RFC6020, it is not recommended to= be used on configuration data. Do you have any suggestion/idea on this augment? Thanks! Regards, Mandy --_000_D970584466921040BD10823F192C30B9382B00EDESGSCMB103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy and all,

 

For configuration change notification in RFC6470, it= only provides “what is changed” via “target” to ne= twork management. It doesn’t have a field be used to provide the deta= il configuration change information about “the configuration is changed to what”. I want to ask for your suggestion about how to aug= ment RFC6470 to provide “the configuration is changed to what ”= .

 

I am considering to add something like “conten= t” for “target”, which is used to contain the detail info= rmation about the configuration changes. But the big question currently is = for the “target” node, it may be a container, a list, a leaf or a leaf-reference, etc. It could be any node of the tree. So we need to = find a common format for the “content” to accommodate different= types of “target”. what I can imagine is anyxml could be used.= But seems it is not a good choice. Because based on RFC6020, it is not recommended to be used on configuration data.

 

Do you have any suggestion/idea on this augment? Tha= nks!

 

Regards,

Mandy

 

 

--_000_D970584466921040BD10823F192C30B9382B00EDESGSCMB103erics_--