Re: [core] CoMI Cool draft splits

Andy Bierman <andy@yumaworks.com> Fri, 20 November 2015 17:49 UTC

Return-Path: <andy@yumaworks.com>
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 49F7F1B3A5F for <core@ietfa.amsl.com>; Fri, 20 Nov 2015 09:49:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 9PSUt7u_Tofl for <core@ietfa.amsl.com>; Fri, 20 Nov 2015 09:49:03 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 078DF1B3A5E for <core@ietf.org>; Fri, 20 Nov 2015 09:49:03 -0800 (PST)
Received: by lbblt2 with SMTP id lt2so66450509lbb.3 for <core@ietf.org>; Fri, 20 Nov 2015 09:49:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mH2uY//xIg4K/o7eyEhen6J/eZivs+GBS+Lt+gaeAGU=; b=n5dt/TEEAIdz0vO6mQEZhPYKIZzenxqLQMcubJjO8X3Kh5bnHO9sso1bTo7GiHBUN+ lKuG+zWrjM2t/E1lgOFkz5E0+TKwvFkey54Wdb5+m+Br6pIWFmbW1N0iHVH5PabwkHH7 JSyhfe/FPG2Na6VwZ0Xt9MQkONUT/mgMRhdXBJ4NhjMbzcBPyDffMNPJlu84Y0SRGn3m 1eypv+xX2HpeMqXUyTU6Lv60NvMqdUTMt4pFbd0K3NEFRqRu3RQ+BWvm5JTJUvw180Bj kpEFvVRCdbZzb1kEBQv+Yv9bj/E3WA9FLfNht2HovwbLwhyz5lQFJD0cV5qrJ07T96S/ PkYw==
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=mH2uY//xIg4K/o7eyEhen6J/eZivs+GBS+Lt+gaeAGU=; b=CvjN+HDAwJQKhM2jTOLk/8kw1acVlwnb610KC4bifHseQ+GqQv4qigjfMgYnioGNAw 4bLwNqsZTJJmRpi2cyxFQSIwXw3jhduJNcwOD/0mkkFrzljSn08Ff7ggZ8UdQW3rCZJP xwTzHoyJWncVyzHQ8PG67rt7mWzw1t3Y5jgkfFF3apk5RGN4bowpJOIu7aq+X8ELcVa8 gOVyWlIZcYgz1SA5crLNNwQ8MqPdC/qhd780+eP6TCIA4FmZsiHHEQAFhw1LADxjWjm9 cx7+zFUfcANH/ODUXJiQnmKD5Ym0FAGuXXHiXFjyPYvKe5tVRGzFgTAU2uy6q51OQyvh DuWw==
X-Gm-Message-State: ALoCoQmu/95Yk450ClBeLi58AIJBN34CRch+BsZeFQ1uSCulEmRoY69WECPeFYBFsoO6Rgap4jpl
MIME-Version: 1.0
X-Received: by 10.112.202.101 with SMTP id kh5mr6433542lbc.66.1448041741064; Fri, 20 Nov 2015 09:49:01 -0800 (PST)
Received: by 10.112.144.106 with HTTP; Fri, 20 Nov 2015 09:49:00 -0800 (PST)
In-Reply-To: <BN1PR04MB42452BD7FF0CFE2BF1258DE921A0@BN1PR04MB424.namprd04.prod.outlook.com>
References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <BN1PR04MB424BAAB4D9E771D891BD06F921D0@BN1PR04MB424.namprd04.prod.outlook.com> <CABCOCHQ8QQArhVUVT4FkYOYnYny4osGMeY4F6jvNjZ0v9Pa3bg@mail.gmail.com> <cf7b132ec85a3781bf4e3a28cda4cb97@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> <CABCOCHROWZtR3jZ431ZK_rxZR-giAr9qzGcANzYSD-a85dSyHQ@mail.gmail.com> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> <CABCOCHTQ6h6zAzL+OyrMT_xKcOzk1=Z7DtaSniQTO2PTOuDW9w@mail.gmail.com> <564DFAD7.1000800@tzi.org> <CABCOCHRU2S9TBMLtEfA_jqHa1+jVC4Sk8hZG0OiVi5q6mP+yXg@mail.gmail.com> <564EBF4A.8010405@tzi.org> <BN1PR04MB42452BD7FF0CFE2BF1258DE921A0@BN1PR04MB424.namprd04.prod.outlook.com>
Date: Fri, 20 Nov 2015 09:49:00 -0800
Message-ID: <CABCOCHTk9+OmqEd2Wj2uNuaJZ57o2SThKX-zKc-OG86pdv1LMw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Rodney Cummings <rodney.cummings@ni.com>
Content-Type: multipart/alternative; boundary="001a11c3724c98b44f0524fc7da7"
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/nKCoCOhLod0IEeBhFpuA6HMZtS4>
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
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: Fri, 20 Nov 2015 17:49:05 -0000

Hi,

I think it will a challenge for the CORE WG to get IANA to manage
the manual number assignment of even IETF modules, let alone all
YANG modules from all vendors and all other SDOs. The cost of even 1 mistake
is rather high (like a wrong port assignment).

YANG Hash will allow any YANG module that has ever been written
or ever could be written to be used without modification or manual
number assignment.

I completely agree with you about CoMI, but not CoOL.


Andy


On Fri, Nov 20, 2015 at 9:36 AM, Rodney Cummings <rodney.cummings@ni.com>
wrote:

> I agree with Carsten on the point below.
>
> As an example, the YANG development in progress for 802.1Q is using
> features, augments, and so on in order to build up modules from the basic
> components to more complex components (e.g. for providers). The basic
> components essentially represent the hardware registers of a switch. As
> constrained products explore integration of an 802.1Q switch in their
> product, the question of a constrained network management protocol comes
> up. IMO CoMI/CoOL provides an excellent solution for this use case, using
> the 802.1Q module(s) for basic components (i.e. modules not specifically
> targeted to constrained).
>
>
> > -----Original Message-----
> > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann
> > Sent: Friday, November 20, 2015 12:36 AM
> > To: Andy Bierman <andy@yumaworks.com>
> > Cc: Core <core@ietf.org>
> > Subject: Re: [core] CoMI Cool draft splits
> >
> > Andy Bierman wrote:
> > > [...] IMO constrained nodes
> > > will never be using the same modules that are written for networking
> > > equipment.
> >
> > Is that so?  Why wouldn't I use a couple of items from, say, RFC 7317
> > (or 7277) in my constrained node?  In the end these are just resources
> > that I add to my resource tree.  Of course, cherry-picking may require
> > some form of subsetting that may not yet be part of the NETCONF approach.
> >
> > Grüße, Carsten
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
>