Re: [core] CoMI Cool draft splits
peter van der Stok <stokcons@xs4all.nl> Wed, 18 November 2015 10:23 UTC
Return-Path: <stokcons@xs4all.nl>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7007B1B2BD2 for <core@ietfa.amsl.com>; Wed, 18 Nov 2015 02:23:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IO-t98_6N4AH for <core@ietfa.amsl.com>; Wed, 18 Nov 2015 02:23:26 -0800 (PST)
Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BACF1B2BCD for <core@ietf.org>; Wed, 18 Nov 2015 02:23:26 -0800 (PST)
Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud6.xs4all.net with ESMTP id iyPQ1r00A4aYjWA01yPQL1; Wed, 18 Nov 2015 11:23:24 +0100
Received: from [2001:983:a264:1:4449:a38c:4f0f:5f7c] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 18 Nov 2015 11:23:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 18 Nov 2015 11:23:24 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Somaraju Abhinav <abhinav.somaraju@tridonic.com>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net>
References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <BN1PR04MB424BAAB4D9E771D891BD06F921D0@BN1PR04MB424.namprd04.prod.outlook.com> <CABCOCHQ8QQArhVUVT4FkYOYnYny4osGMeY4F6jvNjZ0v9Pa3bg@mail.gmail.com>, <cf7b132ec85a3781bf4e3a28cda4cb97@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net>
Message-ID: <4df325ff9500dbdae6f981ac577400d7@xs4all.nl>
X-Sender: stokcons@xs4all.nl (1pEma60ThxKPWh5SNlyYxg/ZowCUeABm)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/1sn7_6XcI_le3R8kzZEhFcli-rw>
Cc: Core <core@ietf.org>
Subject: Re: [core] CoMI Cool draft splits
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2015 10:23:29 -0000
Hi Abhinav, see below. Somaraju Abhinav schreef op 2015-11-18 09:31: > Hi Peter, > I like your proposal of starting with the four drafts. Just a few > comments > > - Before working through iv) function set, I think it makes a little > bit of time working out what use cases we want to support. In > particular, I think we should decide if we are only going to address > Netconf/Restconf support or if we expect to support Yang application > layer module management. In my opinion, in constrained networks we > will not support two management protocols one for networking and one > for application layer. Therefore, we should support both in the > function set. <peter> I agree about support for management and others (which needs a bit of thought) </peter> > > - Access control. I think for iv) function set, we should also think > about how access control is going to work while we look at the > function set. I don't know if this is a separate draft in a different > WG (e.g. ACE). But from the perspective of being able to use a device > management protocol, unless we also get interoperability for access > control/security mechanisms, the drafts will not be usable in the > field. <peter> Again I agree. In the security considerations this should be put forward. I was more thinking of referring to the drafts developed in ACE and COSE than on specifying security separately for CoMI/CoOL. One of my problems is also the support of Multicast, and I don't see the appropriate draft being approved quickly. </peter> > > - Regarding Versions of YANG modules: I do not understand why we need > consistent numbering when a module version gets upgraded. As Rodney > already mentioned, we can not assume that new versions of a module are > supersets of old versions. I think it is also important to keep using > the automated numbering scheme as far as possible. So, my questions is > the following: do we need data node IDs consistent across versions of > YANG modules. <peter> on the other hand there are the YANG rules as Andy pointed out; My take-away till now is that consistent data node IDs across versions is VERY difficult, and probably not needed (to be checked in detail) </peter> > > Abhinav > > ________________________________________ > From: core [core-bounces@ietf.org] on behalf of peter van der Stok > [stokcons@xs4all.nl] > Sent: Wednesday, November 18, 2015 8:27 AM > To: Andy Bierman > Cc: Core > Subject: Re: [core] CoMI Cool draft splits > >> >> I think the YANG Hash draft should be separate from the protocol. >> We want to use it with RESTCONF, as well as the YANG/CBOR encoding. >> > > I agree with Andy here. > Although I sympathize with Rodney, that once the four drafts are > reality, the WG should decide about adoption and a recombination of > documents. > > Peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > ________________________________________________________ The contents > of this e-mail and any attachments are confidential to the intended > recipient. They may not be disclosed to or used by or copied in any > way by anyone other than the intended recipient. If this e-mail is > received in error, please immediately notify the sender and delete the > e-mail and attached documents. Please note that neither the sender nor > the sender's company accept any responsibility for viruses and it is > your responsibility to scan or otherwise check this e-mail and any > attachments.
- [core] CoMI Cool draft splits peter van der Stok
- Re: [core] CoMI Cool draft splits Rodney Cummings
- Re: [core] CoMI Cool draft splits Andy Bierman
- Re: [core] CoMI Cool draft splits Michel Veillette
- Re: [core] CoMI Cool draft splits Michel Veillette
- Re: [core] CoMI Cool draft splits Rodney Cummings
- Re: [core] CoMI Cool draft splits Andy Bierman
- Re: [core] CoMI Cool draft splits Michel Veillette
- Re: [core] CoMI Cool draft splits peter van der Stok
- Re: [core] CoMI Cool draft splits peter van der Stok
- Re: [core] CoMI Cool draft splits Somaraju Abhinav
- Re: [core] CoMI Cool draft splits peter van der Stok
- Re: [core] CoMI Cool draft splits Somaraju Abhinav
- Re: [core] CoMI Cool draft splits peter van der Stok
- Re: [core] CoMI Cool draft splits Somaraju Abhinav
- Re: [core] CoMI Cool draft splits Andy Bierman
- Re: [core] CoMI Cool draft splits Michel Veillette
- Re: [core] CoMI Cool draft splits Rodney Cummings
- Re: [core] CoMI Cool draft splits Somaraju Abhinav
- Re: [core] CoMI Cool draft splits Andy Bierman
- Re: [core] CoMI Cool draft splits Carsten Bormann
- Re: [core] CoMI Cool draft splits Andy Bierman
- Re: [core] CoMI Cool draft splits Carsten Bormann
- Re: [core] CoMI Cool draft splits Somaraju Abhinav
- Re: [core] CoMI Cool draft splits Rodney Cummings
- Re: [core] CoMI Cool draft splits Andy Bierman
- Re: [core] CoMI Cool draft splits Rodney Cummings