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
- [CCAMP] Consideration on Splittng type module for… Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)
- Re: [CCAMP] Consideration on Splittng type module… Mahesh Jethanandani
- Re: [CCAMP] Consideration on Splittng type module… tom petch
- Re: [CCAMP] Consideration on Splittng type module… Mahesh Jethanandani