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

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 12 October 2018 19:25 UTC

Return-Path: <mjethanandani@gmail.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 C8637130E82; Fri, 12 Oct 2018 12:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HcqPso7RlnfE; Fri, 12 Oct 2018 12:25:43 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 BF587130E7B; Fri, 12 Oct 2018 12:25:43 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id 80-v6so6270767pgh.10; Fri, 12 Oct 2018 12:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yyuVJP82b3os2Pph59b/Pn4mxeD0ecWpDYOyYBxDD2c=; b=RWe49nNRBhfwSy1RF7frTerVtmYJw+jIQNimIRdeXFmHim+orljgpVfohG6J58f5e0 n8N6kztANyCZNXRIuJ7VXsFyjvATAKiiPrJaudmcKLspdPZzrowflFVaOqAVCi/g6aJc btOzVYxR/NiwYT3U2qFUFCCPJd5ukmUUaS7Whbq+fnamQ00cK7n5EqIs55KGjAlGPDKZ 6yqWn7ZQAnNAPBnxA+BL4J8UyiFV2RaQ+Zj+Cs1/sKEjN4AWBiAdo1DY/GVi86YIhbZh V5zWDlimzbm2aG0Ea+uwnMx1AwabfMfNGfKOeEYMbPECOLdfb5zsos3E0UQPx3kocQkY S+Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yyuVJP82b3os2Pph59b/Pn4mxeD0ecWpDYOyYBxDD2c=; b=CHG2NxkQ9bhc3w/keqNa4elumIYx4s22FePXBMtEO1Q7Ngq2BBAWbxGeBdYfD7bnnH Uh2sv7BNs3KfAjz3VL2IaZDztVqjEARDyVIBMzcCnh55iUB9WpMCzKpzx6GeLhytBzdm rBTCkl+e5zj1eghxQM07ARoKrzeu15+diHBowQ+gPLmI8lEzCza+3KUAaEdVnutOCM8T UaGTRHLuVnjWvvXTELk0bfM36n15fGQIpOPxp0VLnnC4Rdblcu4puEp8Kt4LKSoohVzX Vbz0K+3VPYhKEV/j8KIlurLW84fGnzTjvsD7UdICIvLQBNXj8rjt0xFM6dTP8AaNunXC Hgmw==
X-Gm-Message-State: ABuFfog5UHGDxNAfJtsJdIqjKwaw0Ulamw1qlmPrU0ZZDgoxgER8v114 poZ5idAqIpUVCrSsAay4MSvKTn93uRU=
X-Google-Smtp-Source: ACcGV63ekYdTa70voAQqzF/NHbpbqnzW8vAiXNyKK4wbVPjBTlheA/WbjDrUEOoUEKlp+VrT2H6RqQ==
X-Received: by 2002:a63:f05:: with SMTP id e5-v6mr6389812pgl.84.1539372343069; Fri, 12 Oct 2018 12:25:43 -0700 (PDT)
Received: from [10.33.122.212] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id 23-v6sm3760349pfy.156.2018.10.12.12.25.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 12:25:42 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <01d401d46245$bcb60d20$4001a8c0@gateway.2wire.net>
Date: Fri, 12 Oct 2018 12:25:41 -0700
Cc: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <zhenghaomian@huawei.com>, "ccamp@ietf.org" <ccamp@ietf.org>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <06A6C81F-A292-4F1C-B1F7-D3F0573CD720@gmail.com>
References: <E0C26CAA2504C84093A49B2CAC3261A43B705196@dggeml511-mbx.china.huawei.com> <5606FA30-C242-4D27-93CA-D2EF8AEC69C7@gmail.com> <01d401d46245$bcb60d20$4001a8c0@gateway.2wire.net>
To: tom petch <ietfc@btconnect.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/qPa9hyx5vZmXSqJr33ck0Xfn_GQ>
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 19:25:47 -0000

Hi Tom,

I still do not see how a churn in the types definition (since as you say, new types appear often) helps progress any of the drafts. 

I would generally agree with you on generic type definitions. The argument for having a separate draft should depend on how closely or generally the types apply to other modules. Note, there is nothing to say that a single draft cannot have multiple modules, e.g. one for types, and another one for topology.

We are talking about type definitions that are specific to TE or types that are specific to OTN. Generally new types for OTN will apply to the OTN topology model or the tunnel model, and TE types that will apply to TE topology and TE model. Would I create a separate RFC for OTN or TE types or rather keep those modules with one of the respective RFCs, is clearly debatable in my mind.

Cheers.

> On Oct 12, 2018, at 9:08 AM, tom petch <ietfc@btconnect.com>; wrote:
> 
> ----- 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
> 
> 
> 
> 

Mahesh Jethanandani
mjethanandani@gmail.com