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

From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Date: Thu, 11 Oct 2018 12:16:44 +0000

Hi, WG,

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.

>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.

Best wishes,
Haomian

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 11 Oct 2018 13:23:19 -0700

> On Oct 11, 2018, at 5:16 AM, Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]> wrote:
> 
> Hi, WG, 
>  
> 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.

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.
>  

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

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

---

From: tom petch <[email-masked]>
Date: Fri, 12 Oct 2018 16:08:49 +0000

----- Original Message -----
From: "Mahesh Jethanandani" <[email-masked]>
Sent: Thursday, October 11, 2018 9:23 PM

> On Oct 11, 2018, at 5:16 AM, Zhenghaomian (Zhenghaomian, Optical
&Microwave Technology Research Dept) <[email-masked]> 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.

> https://www.ietf.org/mailman/listinfo/ccamp
<https://www.ietf.org/mailman/listinfo/ccamp>
Mahesh Jethanandani //YANG Doctor hat

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 12 Oct 2018 12:25:41 -0700

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 <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]