Re: [CCAMP] Consideration on Splittng type module for tech-specific YANG models

tom petch <ietfc@btconnect.com> Fri, 12 October 2018 16:08 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2712130E37; Fri, 12 Oct 2018 09:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.196
X-Spam-Level: ***
X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 zXjpffkXzDsg; Fri, 12 Oct 2018 09:08:52 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0131.outbound.protection.outlook.com [104.47.1.131]) (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 17231130DEB; Fri, 12 Oct 2018 09:08:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GU24Z1p7qbyOetuwY0pMItXhR/5Xq2+tHtE78lG9EvY=; b=E7z5KaWI7sDWfDng4e5SpRrN7zFyRZ2gxnybXsihn9EJayOVYHCZ3bSXcqCNw5iBABSimvGmmwaZvqGl2Fuv/FH526+Xkf32d94yILcCdfJ4VzHuK1hMEwfelcPaSwrAzIBgAOd2aPC4glsUdirCcEomorWWNCP8lwe+zCw1k4k=
Received: from VI1PR07MB0831.eurprd07.prod.outlook.com (10.161.107.154) by VI1PR07MB4768.eurprd07.prod.outlook.com (20.177.57.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.20; Fri, 12 Oct 2018 16:08:49 +0000
Received: from VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db]) by VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db%12]) with mapi id 15.20.1228.020; Fri, 12 Oct 2018 16:08:49 +0000
From: tom petch <ietfc@btconnect.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <zhenghaomian@huawei.com>
CC: "ccamp@ietf.org" <ccamp@ietf.org>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>
Thread-Topic: [CCAMP] Consideration on Splittng type module for tech-specific YANG models
Thread-Index: AQHUYkXc45cue95fhkacAMi02eCZCQ==
Date: Fri, 12 Oct 2018 16:08:49 +0000
Message-ID: <01d401d46245$bcb60d20$4001a8c0@gateway.2wire.net>
References: <E0C26CAA2504C84093A49B2CAC3261A43B705196@dggeml511-mbx.china.huawei.com> <5606FA30-C242-4D27-93CA-D2EF8AEC69C7@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: CWLP265CA0372.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:5e::24) To VI1PR07MB0831.eurprd07.prod.outlook.com (2a01:111:e400:508e::26)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [81.131.229.47]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4768; 6:GPqfcEsNAX6tL4FOLQ/UTvbaiSmZPyq7iXjTpWyuttOfqsdV0ffE9kq8aW0mbeNPsl7iZy2vt7z+0YvZtrajmbje3B7PFSyLfxtWEZuj/tFlFvWXr/Xg5PghP4y31BzRWMduaeCwAXWzY7VL4hjTFAVWIfiNsCKXQge8AK0+Soxkty038CTOiXAvYyeNMteLn9GCextqCNa0sxPS5kaTLe/IGVsJQFQGQ84MHpjY/1XGRt8mi895b6mzLgCN0smUnnYFuXZ43bf4IspD9Rqk9L9l5GJOtsEY9qzOYmcT0PZdPopZT5Xm0KR6zQEW2FcCVJNS+EJupFtWYaPnCGvh/xVZKPl3PIPT6gw7fIpeEPoDSMPfdS8FGoV0+oKKdW2TjcAHjOWqO3GsETamVOBIIZznfgw4CT6QoY8oUT5rlBSjDaKOCWvdu6H8xmQYv17tmF4yoFO8mCwwbP75bGza+g==; 5:FTl1fmJLngJ2qGSeDyFA7w1vWcIuugS5RYmfS25Ra9EXn7ZwEXfHa20NpvFqLZNbM/zpJ+h5WANRkB1mDkZS38esmBIOzsaOH31cmD9E9amu/1lOdJ4ouH8tMVovjgT6nddUa9UOiCcDs1UijGTHN2b6wuw7TbNVcta//naPNkE=; 7:NNSeS0Cr45xevi/SzjDNmEhhI7p52RS9fdCR/cuZIE3653JnZTjg1Gu1W5b7iwUflGaBwhq/uxNMXi7LwW2Kd6cZyxweucXe6W0jLadBZJLQe4b8JLiuc79gU6mtqwfogzywcSDgNqGPQbxQJgXLf+1pjUl1s7DHAti4cDwDul0JZxpMnwEyRwp4DYjo1hZ9enTca0lTik82IucyQQKJ/P7WPhB+b9ogNMnJN/0avqjOs3PXw7V17OhyiRjlfs40
x-ms-office365-filtering-correlation-id: 50754e9e-e7f8-4af6-db81-08d6305cfef4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB4768;
x-ms-traffictypediagnostic: VI1PR07MB4768:
x-microsoft-antispam-prvs: <VI1PR07MB4768F14A21332B0109C4F28DA0E20@VI1PR07MB4768.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(85827821059158)(50582790962513);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051); SRVR:VI1PR07MB4768; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4768;
x-forefront-prvs: 0823A5777B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39860400002)(396003)(376002)(366004)(189003)(52014003)(199004)(13464003)(106356001)(6436002)(476003)(25786009)(478600001)(105586002)(486006)(5250100002)(446003)(68736007)(186003)(4326008)(39060400002)(2900100001)(14454004)(966005)(97736004)(6246003)(256004)(81156014)(316002)(81166006)(26005)(8676002)(33896004)(54906003)(71200400001)(71190400001)(6486002)(3846002)(6116002)(229853002)(8936002)(66066001)(305945005)(44736005)(102836004)(7736002)(6506007)(386003)(53936002)(53546011)(110136005)(76176011)(84392002)(2906002)(6306002)(9686003)(6512007)(99286004)(1556002)(5660300001)(86152003)(86362001)(52116002)(14496001)(170073001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4768; H:VI1PR07MB0831.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Yjohx0Wq+Ns0gZhQjCmDqMY4tQ1MgXo1BLMN+i8gFzohrIVDF8RXbN3v79sXPFHtVFQGWVEnPucs3KosngIsqYpYLAXoe51OqwlQoWuFpOR8CGZnJVOkVl/SoD3YYlISyhR+ReJUFlvRQPJAeAy+MVq2nDmarqR0RaREKFUDr38DFtf3l4HF3p5F1a9Rnf0h786RjOX5zrL3J7ifVQFd81zVIs3RFv9CqF7TVePqlwBjmgj2TsVg9gGw0bnTnPmytCficVshb3deJwFjOf3k5EQ+TBheF6xi1GYZ6mZ73RFMmHAQsu682upSN+6XISyH0kR33cbIaB1iiysYd4raPpiBv9YRmTBHRmdykDQzd6g=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <FF24F5BB2EB01549B534993ABE0E8F90@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 50754e9e-e7f8-4af6-db81-08d6305cfef4
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2018 16:08:49.5280 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4768
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/7CCUNl0y0u9r4DjYoSWHWTJdns8>
Subject: Re: [CCAMP] Consideration on Splittng type module for tech-specific YANG models
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Oct 2018 16:08:55 -0000

----- Original Message -----
From: "Mahesh Jethanandani" <mjethanandani@gmail.com>
Sent: Thursday, October 11, 2018 9:23 PM

> On Oct 11, 2018, at 5:16 AM, Zhenghaomian (Zhenghaomian, Optical
&Microwave Technology Research Dept) <zhenghaomian@huawei.com> wrote:
>
> As you may know, the teas working group split the ietf-te-types as a
separate document draft-ietf-teas-yang-te-types
<https://tools.ietf.org/wg/teas/draft-ietf-teas-yang-te-types/>. The
module ietf-te-types is imported in both ietf-te-topology module and
ietf-te module, so a separation would help progress these drafts.

I am not sure it helps progress any of the documents. And I do not think
that that should be reason to split the draft. The reason has to be
because the types defined are used by multiple modules. If it is just
another draft that needs this type, you might still be better off
leaving them in one of the drafts.

<tp>
Disagree.  The reason to have a separate module is because it represents
a coherent, more or less self-contained, body of data that is used in
several places.  I express it like that to differentiate putting e.g.
types in a separate module, which I think works well, from putting
grouping in a separate module which I think is usually a bad idea.

However, given that the separation of module has been done, and I would
not suggest reversing that, then whether or not they should be in a
separate RFC should rest upon what the future holds, looking beyond the
process of turning I-D into RFC.  Updating RFC is work, effort, the
opportunity to make mistakes, so having a separate RFC for types is
sensible if the likely lifecycle of the two items is different.

If types remains the same, as RFC6991 has, then it is a good thing.  If
it needs updating at regular intervals because new types emerge, then it
should probably be under the control of IANA, with e.g. a designated
expert to authorise changes which again argues for a separate RFC..

But the key is how often it changes compared to the rest of the two
current I-D; my guess would be that the changes will come at different
times, at different
rates, and so splitting makes sense, even if generating three RFC is
more work that having two RFC (but I have not done my homework to see
how often new types have appeared over the past, say, 30 years; rather
often is my sense).

In passing, there are a number of admin type defects in these I-Ds one
of which is germane to this discussion
"  import ietf-otn-types {
    prefix "otn-types";
    reference
         "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
          Engineering Tunnels and Interfaces";
"
Really?

Tom Petch

Separating them does not make them go any faster. You will need to have
a normative reference to where the te types are defined, and if the
document containing te types is not ready, it will cause other drafts to
be stuck in MISREF.

>
> From the perspective of ccamp, the same issue applies on OTN drafts as
well. In both of the draft-ietf-ccamp-otn-topo-yang
<https://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-otn-topo-yang/>
(speficy module ietf-otn-topology) and draft-ietf-ccamp-otn-tunnel-model
<https://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-otn-tunnel-model/>
(specify module ietf-otn-tunnel), the module ietf-otn-types (currently
also defined in draft-ietf-ccamp-otn-tunnel-model
<https://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-otn-tunnel-model/>)was
imported. To address the potential issue on publish topology without
mature types supporting, two possible approaches would be helpful, 1)
split out the otn-types as a separate draft, as how teas WG is doing; 2)
move the current otn-types into draft-otn-topology, which will probably
come earlier than draft-otn-tunnel, as how WSON-specific module is
doing.
>
> The authors are open to any of these two approaches, and expect our
decision before YANG doctor review of any documents. We also wish the
module otn-types can be reviewed at the first iteration. Thank you.

Do not think that helps. YANG doctors like to see not just the types, bu
t how they are used. You should send the documents as a bundle.

>
> Best wishes,
> Haomian
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org <mailto:CCAMP@ietf.org>
> https://www.ietf.org/mailman/listinfo/ccamp
<https://www.ietf.org/mailman/listinfo/ccamp>
Mahesh Jethanandani //YANG Doctor hat