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

[Mahesh Jethanandani <[e-mail]>]

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 <[e-mail]> wrote:
> 
> ----- Original Message -----
> From: "Mahesh Jethanandani" <[e-mail]>
> Sent: Thursday, October 11, 2018 9:23 PM
> 
>> On Oct 11, 2018, at 5:16 AM, Zhenghaomian (Zhenghaomian, Optical
> &Microwave Technology Research Dept) <[e-mail]> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ccamp
> <https://www.ietf.org/mailman/listinfo/ccamp>
> Mahesh Jethanandani //YANG Doctor hat
> 
> 
> 
> 

Mahesh Jethanandani
[e-mail]