Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 07 July 2017 18:13 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C0B131621; Fri, 7 Jul 2017 11:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 X5jIDJGyUay2; Fri, 7 Jul 2017 11:13:38 -0700 (PDT)
Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 1FCC7126C0F; Fri, 7 Jul 2017 11:13:38 -0700 (PDT)
Received: by mail-pg0-x244.google.com with SMTP id u36so4900960pgn.3; Fri, 07 Jul 2017 11:13:38 -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:message-id:references :to; bh=cuVrbV0j/sunc9+fw7rZT07kE6h5nDuGnGvCdgvX31o=; b=ZNi9Sn6OUuIEKL4VxyR3pig4sU4qVKUA9ubRnPGYwBi7umFmyaksy3HKBbHqSmv+kF XBHvzjpdUz4Wk+alRlvkgT9/4zCb3CWiRjvcZdu0s0TsYCR1Gi+G/la2fglCTCLKQwNg oKfWwW532uI6iklKwbqmgZ0FsOkKMpWb8HhMZ2AzjGssiCqV01VxApNF79qskLlmFpXT 6ZJsOYLxtEKpz6lBDB6XJkGEbdIq72brcbnLIAUElF1LQ6cTT8FGL63ertsMGLvVVlMP sTZwSbanjA9wbn2KE8wq+yS28IFuWIB/DG+thTx7CjWQitK2ioSir/BL0czktrGIqJz/ uwfA==
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 :message-id:references:to; bh=cuVrbV0j/sunc9+fw7rZT07kE6h5nDuGnGvCdgvX31o=; b=RP4+eFu/PMeQz4tUNYbb9q+zUoNmt4GVDFapEuZl1pBE6QNcexUY8dIvZIjuuxnGJ8 g3bt9bfvEqBX04QUh2I7EzlFXcgnQdYBUh0+gtVoEHkc0aBOSnr/OoePof/G+pD3Q5oz vaWN+1jQDPAbij+ve1symqMBtieJGYQSs2qhT63yFktPCMLxSQPtC8IpjYmsPqCo35x7 zgpzyhn6Ea64aSDcnYGAk/c5V94N0a41BYrGFflJyVhy58NByy6gJGQvKM4CW/DSz8GY VVjrA6tyAghZVS+39XzVBDZpcUV1VermJxhJBvExoKQewSUSS5Zh3f1botRG4lw1Zh6/ VOaQ==
X-Gm-Message-State: AIVw1134Ub6z09q+qGY6b27ifFlxhNrQVMQuTrpEyfnUd8MOq2OxJuKj V5+qCOCnPpJcfw==
X-Received: by 10.84.194.37 with SMTP id g34mr4491042pld.111.1499451217575; Fri, 07 Jul 2017 11:13:37 -0700 (PDT)
Received: from ?IPv6:2602:306:cf77:df90:ece3:5fed:de5b:51da? ([2602:306:cf77:df90:ece3:5fed:de5b:51da]) by smtp.gmail.com with ESMTPSA id t78sm8917402pfa.48.2017.07.07.11.13.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Jul 2017 11:13:36 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_878BBB3D-E53E-4A9D-9A7D-69573F8471A8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <024a01d2f44b$465229c0$d2f67d40$@gmail.com>
Date: Fri, 7 Jul 2017 11:13:35 -0700
Cc: Robert Wilton <rwilton@cisco.com>, Benoit Claise <bclaise@cisco.com>, Xufeng Liu <Xufeng_Liu@jabil.com>, yang-doctors@ietf.org, ietf@ietf.org, teas@ietf.org, draft-ietf-teas-yang-te-topo.all@ietf.org
Message-Id: <57EAC7E8-66B5-43D7-AA03-3D5E1008FC49@gmail.com>
References: <149564066257.28529.12761629961042171907@ietfa.amsl.com> <BN3PR0201MB08670E55FFB5470F338E998DF1CD0@BN3PR0201MB0867.namprd02.prod.outlook.com> <5d4541d3-9426-787d-e02b-9c2dbc3a5400@cisco.com> <BN3PR0201MB0867315F3E88577B9EEF6584F1DB0@BN3PR0201MB0867.namprd02.prod.outlook.com> <3a1c319f-0255-b8ee-ecbd-739568c1dc7f@cisco.com> <1ab3a0d8-de3e-1d7c-2967-97b74b1c68a5@cisco.com> <BN3PR0201MB0867664CBDA460C283DC8043F1DB0@BN3PR0201MB0867.namprd02.prod.outlook.com> <04b933e2-189a-6fe2-5d24-310167f91b69@cisco.com> <00d001d2f37c$22d3dd10$687b9730$@gmail.com> <a83f8acd-2c14-2d28-f196-96b5fd7833a9@cisco.com> <024a01d2f44b$465229c0$d2f67d40$@gmail.com>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/USYmBL4h5ZKX9cPj3CZJ1zBPTQM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2017 18:13:42 -0000

Also, couple of changes in the YANG modules:

Under revision, can you make sure there is a reference back to the RFC number that will be assigned to the draft. Something like:

  revision "YYYY-MM-DD" {
    description
     "Initial version";
    reference
     "RFC XXXX: YANG - TE Topology";
  }

with a note to RFC editor to replace XXXX with the number assigned to the RFC.

Prefix organization with IETF. Something like “IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group”

Thanks.


> On Jul 3, 2017, at 3:25 PM, Xufeng Liu <xufeng.liu.ietf@gmail.com> wrote:
> 
> HI Rob,
>  
> Just posted https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ <https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/>  to fix the snippets, along with a missing IANA entry.
>  
> Thanks,
> - Xufeng
>  
> From: Robert Wilton [mailto:rwilton@cisco.com] 
> Sent: Monday, July 3, 2017 5:13 AM
> To: Xufeng Liu <xufeng.liu.ietf@gmail.com>om>; 'Benoit Claise' <bclaise@cisco.com>om>; 'Xufeng Liu' <Xufeng_Liu@jabil.com>om>; 'Mahesh Jethanandani' <mjethanandani@gmail.com>om>; yang-doctors@ietf.org
> Cc: ietf@ietf.org; teas@ietf.org; draft-ietf-teas-yang-te-topo.all@ietf.org
> Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08
>  
> Hi Xufeng,
> Thanks for updating the modules to be NMDA compliant.  I think that getting structural consistency across the IETF YANG modules will make them far more compelling as a solution.
> I noticed that some of the snippets of YANG tree output in the draft still illustrate using the "split oc-style config/state structure" and hence also need to be updated.  Probably this could be done as part of the WG LC.
> To find the instances, just search the draft for "rw config" and "ro state".
> Thanks,
> Rob
>  
> On 02/07/2017 22:42, Xufeng Liu wrote:
>> An updated revision of the TE topology model has been posted at https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-10 <https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-10>.
>>  
>> This new revision now contains the NMDA compliant module and a companion “-state” module, after the I2RS topology model that we augment has been update with a “-state” module.
>>  
>> Now that this issue has been solved, the authors and contributors think that the draft is ready for the last call.
>>  
>> Thanks,
>> - Xufeng
>>  
>> P.S. Because of the structure changes of the TE topology model, all augmenting models need to be updated. Sorry for the short notice.
>>  
>> From: Teas [mailto:teas-bounces@ietf.org <mailto:teas-bounces@ietf.org>] On Behalf Of Benoit Claise
>> Sent: Monday, June 26, 2017 6:46 AM
>> To: Xufeng Liu <Xufeng_Liu@jabil.com> <mailto:Xufeng_Liu@jabil.com>; Robert Wilton <rwilton@cisco.com> <mailto:rwilton@cisco.com>; Mahesh Jethanandani <mjethanandani@gmail.com> <mailto:mjethanandani@gmail.com>; yang-doctors@ietf.org <mailto:yang-doctors@ietf.org>
>> Cc: Benoit Claise <bclaise@cisco.com> <mailto:bclaise@cisco.com>; ietf@ietf.org <mailto:ietf@ietf.org>; teas@ietf.org <mailto:teas@ietf.org>; draft-ietf-teas-yang-te-topo.all@ietf.org <mailto:draft-ietf-teas-yang-te-topo.all@ietf.org>
>> Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08
>>  
>> Hi Xufeng,
>>> Hi Benoit,
>>>  
>>>> -----Original Message-----
>>>> From: Benoit Claise [mailto:bclaise@cisco.com <mailto:bclaise@cisco.com>]
>>>> Sent: Thursday, June 22, 2017 6:12 AM
>>>> To: Robert Wilton <rwilton@cisco.com> <mailto:rwilton@cisco.com>; Xufeng Liu <Xufeng_Liu@jabil.com> <mailto:Xufeng_Liu@jabil.com>;
>>>> Mahesh Jethanandani <mjethanandani@gmail.com> <mailto:mjethanandani@gmail.com>; yang-doctors@ietf.org <mailto:yang-doctors@ietf.org>
>>>> Cc: ietf@ietf.org <mailto:ietf@ietf.org>; teas@ietf.org <mailto:teas@ietf.org>; draft-ietf-teas-yang-te-topo.all@ietf.org <mailto:draft-ietf-teas-yang-te-topo.all@ietf.org>
>>>> Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-
>>>> 08
>>>>  
>>>> Dear draft-ietf-teas-yang-te-topo authors,
>>>>> Hi Xufeng,
>>>>>  
>>>>> OK, by tooling, I don't mean the pyang plugins that I have been
>>>>> working on to convert between different types of models.  As you
>>>>> aware, the TE YANG models can easily be converted to NMDA style since
>>>>> I have already done it
>>>>> (https://github.com/rgwilton/ietf-models-to-combined <https://github.com/rgwilton/ietf-models-to-combined>).
>>>>>  
>>>>> My comment actually relates to the fact the structure used by TE YANG
>>>>> modules don't match any other YANG modules - they are using their own
>>>>> unique style of structure.
>>>> This is an important issue to resolve.
>>>>>  
>>>>> Today, there are three common styles of modules:
>>>>> (1) IETF style split config/state trees (e.g. ietf-interfaces).
>>>>> (2) IETF NMDA style combined config/state trees (i.e. where all IETF
>>>>> modules are heading to).
>>>>> (3) OpenConfig style modules with the config/state containers
>>>>> immediately above the config leaves.
>>>>>  
>>>>> Tooling is likely to be optimized to work with these model structures,
>>>>> but the TE modules do not fit into any of the three styles above.
>>>>> They are a yet another OpenConfig-like style, but that is different
>>>>> enough that tooling that is designed to work with OpenConfig style
>>>>> YANG modules would likely not work with the TE YANG modules.
>>>>>  
>>>>> Specifically, for clients that expecting to work with an OpenConfig
>>>>> style YANG module, then if it knows the path to config leaf X, then
>>>>> they would expect the applied config value to be available at the path
>>>>> "../state/X".  But, this doesn't hold for the structure being used in
>>>>> the TE YANG models.
>>>>>  
>>>>> I believe strongly that the models being produced by organizations
>>>>> should be structures in a consistent way, hence why I think that the
>>>>> published standard version of the TE YANG modules should immediately
>>>>> align to the NMDA style.
>>>> Agreed.
>>>> Here is the OPS and RTG AD message:
>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg18252.html <https://www.ietf.org/mail-archive/web/netmod/current/msg18252.html>
>>>>  
>>>> I understand that the I2RS topology YANG modules will be improved to the
>>>> NMDA style.
>>> [Xufeng] The I2RS topology model is already NMDA style, but the NMDA models are not immediately implementable without NETCONF/RESTCONF protocol update. We will need the "-state" module for the I2RS topology model (and for all the top-level models) for now. 
>> Adding -state to the Appendix is a possibility.
>> "In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix."
>> See https://www.ietf.org/mail-archive/web/netmod/current/msg18252.html <https://www.ietf.org/mail-archive/web/netmod/current/msg18252.html>
>> 
>> 
>>> While the NMDA is nice, the NMDA discussions have already significantly delayed publishing new models, and doing NMDA without staging will further delay the process.
>> This is not solving the important issue brought up by Rob Witlon:
>>> My comment actually relates to the fact the structure used by TE YANG modules don't match any other YANG modules - they are using their own unique style of structure.
>> Regards, B.
>> 
>> 
>>>  
>>> Thanks,  Xufeng
>>>>  
>>>> Regards, Benoit
>>>>>  
>>>>> Thanks,
>>>>> Rob
>>>>>  
>>>>>  
>>>>> On 22/06/2017 04:16, Xufeng Liu wrote:
>>>>>> Hi Rob,
>>>>>>  
>>>>>> While the tooling is very nice to have, especially for writing new
>>>>>> models or converting models, we do not have to use it for every
>>>>>> model. It seems not necessary to use the tooling on this model for
>>>>>> now. We already know that we can manually convert it to NMDA style if
>>>>>> needed.
>>>>>>  
>>>>>> Thanks,
>>>>>> - Xufeng
>>>>>>  
>>>>>>> -----Original Message-----
>>>>>>> From: Robert Wilton [mailto:rwilton@cisco.com <mailto:rwilton@cisco.com>]
>>>>>>> Sent: Wednesday, June 21, 2017 5:34 AM
>>>>>>> To: Xufeng Liu <Xufeng_Liu@jabil.com> <mailto:Xufeng_Liu@jabil.com>; Mahesh Jethanandani
>>>>>>> <mjethanandani@gmail.com> <mailto:mjethanandani@gmail.com>; yang-doctors@ietf.org <mailto:yang-doctors@ietf.org>
>>>>>>> Cc: ietf@ietf.org <mailto:ietf@ietf.org>; teas@ietf.org <mailto:teas@ietf.org>;
>>>>>>> draft-ietf-teas-yang-te-topo.all@ietf.org <mailto:draft-ietf-teas-yang-te-topo.all@ietf.org>
>>>>>>> Subject: Re: [Teas] Yangdoctors last call review of
>>>>>>> draft-ietf-teas-yang-te-topo-
>>>>>>> 08
>>>>>>>  
>>>>>>> Hi Xufeng,
>>>>>>>  
>>>>>>> On 12/06/2017 22:28, Xufeng Liu wrote:
>>>>>>>> Hi Mahesh,
>>>>>>>>  
>>>>>>>> Thank you much for the review. We have submitted an updated draft
>>>>>>> (https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-09 <https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-09>) to
>>>>>>> address these issues. More detailed explanations are put below
>>>>>>> inline.
>>>>>>>> If the responses and updates are satisfactory, we are ready for the
>>>>>>>> last call.
>>>>>>>>  
>>>>>>>> Best regards,
>>>>>>>> - Xufeng
>>>>>>>>  
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>]
>>>>>>>>> Sent: Wednesday, May 24, 2017 11:44 AM
>>>>>>>>> To: yang-doctors@ietf.org <mailto:yang-doctors@ietf.org>
>>>>>>>>> Cc: ietf@ietf.org <mailto:ietf@ietf.org>; teas@ietf.org <mailto:teas@ietf.org>;
>>>>>>>>> draft-ietf-teas-yang-te-topo.all@ietf.org <mailto:draft-ietf-teas-yang-te-topo.all@ietf.org>
>>>>>>>>> Subject: Yangdoctors last call review of
>>>>>>>>> draft-ietf-teas-yang-te-topo-08
>>>>>>>>>  
>>>>>>>>> Reviewer: Mahesh Jethanandani
>>>>>>>>> Review result: Ready with Issues
>>>>>>>>>  
>>>>>>>>> Document reviewed: draft-ietf-teas-yang-te-topo-08
>>>>>>>>>  
>>>>>>>>> Status: Ready with Issues
>>>>>>>>>  
>>>>>>>>> I am not an expert in Traffic Engineering. This review is looking
>>>>>>>>> at the draft from a YANG perspective. With that said, I have
>>>>>>>>> marked it as “Ready
>>>>>>> with Issues”
>>>>>>>>> because of some of the points discussed below.
>>>>>>>>>  
>>>>>>>>> Summary:
>>>>>>>>>  
>>>>>>>>> This document defines a YANG data model for representing,
>>>>>>>>> retrieving and manipulating TE Topologies. The model serves as a
>>>>>>>>> base model that other technology specific TE Topology models can
>>>> augment.
>>>>>>>>>  
>>>>>>>>> Comments:
>>>>>>>>>  
>>>>>>>>> Almost all the containers in the model are presence containers. Is
>>>>>>>>> there a reason why they have to be presence containers? Note, that
>>>>>>>>> presence containers are containers whose existence itself
>>>>>>>>> represents configuration data. What particular configuration data
>>>>>>>>> is each container
>>>>>>> representing in itself?
>>>>>>>> [Xufeng] Containers that use “presence” are:
>>>>>>>>     - Container “underlay”
>>>>>>>>       o  We have changed 13 occurrences of such containers to be
>>>>>>>> not
>>>>>>> presence container.
>>>>>>>>     - Container “te” under augmentation
>>>>>>>>       o  To indicate that “TE” is enabled (configuration data)
>>>>>>>>       o  Also used to do augmentation. The “presence” statement can
>>>>>>> prevent the mandatory child from affecting augmented base model.
>>>>>>>>     - /nw:networks/nw:network/nw:network-types/te-topology!
>>>>>>>>       o  A mechanism required by I2RS topology model to specify the
>>>>>>> topology type.
>>>>>>>>> It is difficult to co-relate the diagram with the model itself
>>>>>>>>> because of different terms being used to define different parts of
>>>>>>>>> the model.
>>>>>>>>> There is “TE Topology Model” and then there is “Generic TE
>>>>>>>>> Topology
>>>>>>> Model”.
>>>>>>>>> Are these one and the same models? If so, a common term for both
>>>>>>>>> of them would be helpful.
>>>>>>>> [Xufeng] Yes. These two terms are the same. Figure 12, Figure 13,
>>>>>>>> and relevant
>>>>>>> descriptions have been updated to make the document consistent.
>>>>>>>>> There is extensive use of groupings in the document. However, not
>>>>>>>>> all instances of groupings are used multiple number of times.
>>>>>>>>> Where they are not being repeated, it would be better to move the
>>>>>>>>> grouping directly where the uses statement resides. Case in point
>>>>>>>>> the grouping
>>>>>>> connectivity-label-restriction-list.
>>>>>>>> [Xufeng] We have removed the following groupings
>>>>>>>>       te-link-augment
>>>>>>>>       te-node-augment
>>>>>>>>       te-termination-point-augment
>>>>>>>>       te-topologies-augment
>>>>>>>>       te-topology-augment
>>>>>>>>       te-link-state-underlay-attributes
>>>>>>>>       te-node-state-derived-notification
>>>>>>>>       te-topology-type
>>>>>>>>  
>>>>>>>> The remaining groupings have been kept so that we can:
>>>>>>>>     - Share the groupings in this model
>>>>>>>>     - Prepare to be shared by a model augmenting this model
>>>>>>>>     - Prevent a grouping or configuration section from being too long
>>>>>>>>     - Improve readability
>>>>>>>>  
>>>>>>>>> The split between config and state containers does not seem to
>>>>>>>>> follow any particular pattern.
>>>>>>>> [Xufeng] The pattern is clear:
>>>>>>>> For each manageable entity (object), there is a config container
>>>>>>>> and state
>>>>>>> container. The configurable properties go into the config container
>>>>>>> and state properties go into the state container. Such objects are
>>>>>>> identified by a list item or a presence container so that the
>>>>>>> “create”, “delete”, and “modify”
>>>>>>> operations
>>>>>>> can be performed on them. The non-presence containers do not
>>>>>>> represent configuration data so they do not introduce such objects.
>>>>>>>>> It is neither a top level split, as is the case with existing IETF
>>>>>>>>> models,
>>>>>>>> [Xufeng] We could not do top level split because the base I2RS
>>>>>>>> network
>>>>>>> topology model
>>>>>>> (https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo <https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo>-
>>>>>>> 12) that we augment does not have the top-level split (for its own
>>>>>>> reasons).
>>>>>>>>> nor do they follow the OpenConfig style of splitting config and
>>>>>>>>> state under each relevant leaf,
>>>>>>>> [Xufeng] The pattern is consistent with this style in principle,
>>>>>>>> with some
>>>>>>> adjustments to fit to our multiple levels of hierarchy.
>>>>>>> This is effectively a new forth style of YANG models that is not
>>>>>>> consistent with any of the three existing styles, i.e.:
>>>>>>>    - Current IETF config/state split model style
>>>>>>>    - NMDA combined config/state tree
>>>>>>>    - OpenConfig split config/state containers immediately above the
>>>>>>> config true leaves.
>>>>>>>  
>>>>>>> Tooling that it designed to work with OpenConfig models will need
>>>>>>> customization to work with these TE models because the config/state
>>>>>>> containers will not be where the tooling expects them to be.
>>>>>>>  
>>>>>>> Thanks,
>>>>>>> Rob
>>>>>  
>>>>> .
>>>>>  
>>>  
>>  
>  

Mahesh Jethanandani
mjethanandani@gmail.com