Re: [core] CoMI Cool draft splits

Andy Bierman <andy@yumaworks.com> Tue, 17 November 2015 17:33 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 97E751A6EE2 for <core@ietfa.amsl.com>; Tue, 17 Nov 2015 09:33:17 -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 N00BEOOC2Vgw for <core@ietfa.amsl.com>; Tue, 17 Nov 2015 09:33:15 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 AFE461A6EE1 for <core@ietf.org>; Tue, 17 Nov 2015 09:33:14 -0800 (PST)
Received: by lfs39 with SMTP id 39so10112576lfs.3 for <core@ietf.org>; Tue, 17 Nov 2015 09:33:12 -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=eV9TYAc0DeKfI9f6s3ebksDpvmP3WOrAHUn2LoNPuSk=; b=TILyAnxCyUK2r70KnqZX9/F8Iyp6TAQ7d/ePOLnVikvGYT5/edU8SBn0Ze4oLtc1Z0 +Y6S550emVptl47nFFF0BkbSXkMykYKCRAerKCOXYYnVVrBPTnNYbQdcQRWlYGtg3qKO iuyS+E01re7LnzCatPzXSYdGVcSmxNACJQmzZDvinuO9Ncf7Bot0TOJyyAvjwABoqI5t Uuf63txfgeOVsviVIcfztjkcqrhEuKTsiUdxXIMsA3xO9FFUKzV9BRueiK78xmxkZCuF Hg/nP9JFKQke8XfH3rBOFhrjQRdd4gx42+ZSg0SWaBOtFm+o/0SfZb/Jr+XnHNed8atJ 8WFw==
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=eV9TYAc0DeKfI9f6s3ebksDpvmP3WOrAHUn2LoNPuSk=; b=SjUerN0si/Wz9EAxe/kVn74ZoXZ8iSZXfxMTCp9f785tptBYdnkbgzdA5CuvWDk7l5 m9upyvBf967K3AHYe6weP77SgTfX+eBubW1V3LOiT6GjY5jT05SaR4VEyOsAjk0gfFSE 8fmZo8zXATIAbpCP6oYBYS0c2L5gdZ1Kctouar2Hx686CgzsOQ9TtOwALpPO1JastefY FmTAWfMyd9M+HOnymkCjd76fQ7vc32rSpPu/u3neD2VqFrzEvwvCSQ+btDyiRneC8xUG zThiL1WwEii4P5+29u6LJKELb6+Dvo68vxcrcBt+4Njv67Hl+pDomldR8jHc/2/hTaYg RqxA==
X-Gm-Message-State: ALoCoQkhkWgCL1KQCEDkikJD+H0EzoCc9udfPlwAETGtWDlLXqZPo1za2WV2uB7J4JAxFLGpmS0a
MIME-Version: 1.0
X-Received: by 10.25.18.209 with SMTP id 78mr20548059lfs.54.1447781592713; Tue, 17 Nov 2015 09:33:12 -0800 (PST)
Received: by 10.112.144.106 with HTTP; Tue, 17 Nov 2015 09:33:12 -0800 (PST)
In-Reply-To: <BN1PR04MB424BAAB4D9E771D891BD06F921D0@BN1PR04MB424.namprd04.prod.outlook.com>
References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <BN1PR04MB424BAAB4D9E771D891BD06F921D0@BN1PR04MB424.namprd04.prod.outlook.com>
Date: Tue, 17 Nov 2015 09:33:12 -0800
Message-ID: <CABCOCHQ8QQArhVUVT4FkYOYnYny4osGMeY4F6jvNjZ0v9Pa3bg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Rodney Cummings <rodney.cummings@ni.com>
Content-Type: multipart/alternative; boundary="001a114065e88be48c0524bfebf1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/iwjNjXepLNj6fFSyA6a1O2AVhaw>
Cc: peter van der Stok <stokcons@xs4all.nl>, 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: Tue, 17 Nov 2015 17:33:17 -0000

On Tue, Nov 17, 2015 at 7:51 AM, Rodney Cummings <rodney.cummings@ni.com>
wrote:

> Thanks Peter,
>
> At this time, proceeding with 4 drafts sounds good to me.
>
> Nevertheless, as we get closer to progressing these in a WG, I think we
> should transition to 2 drafts:
> a) YANG to CBOR mapping ( i) )
> b) Select either hash ( ii) ) or registry ( iii) ), and merge that with
> the function set ( iv) ) for a single draft
>
>

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.



> As for the motivation and use cases, I wonder if it might be helpful to
> state our assumptions for the client side. I would claim that:
> 1. A client cannot assume that the YANG modules implemented by the server
> have been enhanced specifically for CoMI/CoOL.
> 2. A client cannot assume that the YANG objects of a module are distinct
> from a hashing perspective.
> 3. A client cannot assume that a new revision of a module is backward
> compatible to an older revision of that module (i.e. old is proper subset).
> If these assumptions are correct, then the client must perform some
> processing of the server's YANG modules prior to using CoMI/CoOL, and that
> may help to decide between hash/registry.
> If these assumptions are incorrect, it might be useful to discuss it in
> the draft, to provide some background rationale.
>


I do not think manual management of YANG object identifiers is
a workable design.  It assumes that all modules will be registered
with some centralized naming authority.  I do not see how every module
will be registered.  This means unregistered modules cannot be used at all.
The manual numbering also has a hard-limit of 1024 objects per YANG module.
If a module ever has more than 1024 nodes, the "extra" nodes are unusable.

It can be very difficult to manually number objects:

module A {
   grouping A1 {
       leaf X { ... }
       leaf Y { ... }
    }
}

module B {
   import A { prefix A1; }

   container B1 {
     uses A:A1;
   }
   leaf B2 { ... }
}


NEXT RELEASE:

module A {
   grouping A1 {
       leaf X { ... }
       leaf Y { ... }
       leaf Z { ... }
    }
}


If the grouping A:A1 is ever extended, there is no way to number the new
objects
in module B.  All objects after the "uses A:A1" will renumber if new nodes
are
added to the external grouping (which is broken!)
Since this is a very common usage scenario in YANG, this problem will
happen a lot over time.

YANG Hash has the complexity of identifying the hash collision and reading
the rehash mapping info.  Manual numbering has the complexity of managing
the numbering space and dealing with unregistered modules.

I don't see how a client would make this hash vs. managed numbers decision
at run-time.
It is not as if the CoMI server will provide multiple ways of numbering
objects.
Giant routers do not even do that, let alone constrained devices.

Unless CoMI uses unmodified YANG modules, it does not really support YANG.



> Rodney
>
>
Andy


> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok
> Sent: Tuesday, November 17, 2015 3:41 AM
> To: Core <core@ietf.org>
> Subject: [core] CoMI Cool draft splits
>
> Hi all,
>
> During the Yokohama meeting I proposed to split the CoMI/CoOl drafts
> into three parts as suggested by Juergen Schoenwalder in a separate
> earlier communication.
> This e_mail sets out in more detail why the proposed split is a good
> one.
>
> The proposed three parts are:
> 1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL)
> 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL)
> 3) The YANG name compression (section 5 in CoMI; section 6 in CoOL)
>
> The split has two advantages:
> - the parts 2 and 3 can be used in other contexts, e.g. RESTCONF
> - It separates out the issues which need to be solved to merge CoOL and
> CoMI.
>
> I come to the generation of 4 drafts:
> i) The YANG to CBOR mapping.
> ii) Hashing of YANG names
> iii) Managed identifier assignment to YANG names
> iv) The Function set specification
>
> Ad i) I don't expect a long list of issues for the merging. However, it
> may be advisable to submit the draft to the netmod WG, where much of the
> YANG expertise exists and the draft can be aligned with the YANG to JSON
> draft.
> Ad ii and iii) These approaches are very different and merit independent
> drafts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts.
> It is also possible that drafts get submitted to other WGs.
> Ad iv) In my view the alignment of the two existing approaches, CoMI and
> CoOL, may take some time. I will be happy if in Buenos Aires we have a
> list with issues, accompanying motivation, and use cases.
>
> Is this a valid approach? Comments are solicited.
>
> Peter
>
> --
> Peter van der Stok
> vanderstok consultancy
> mailto: consultancy@vanderstok.org
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>