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, 07 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>; 'Benoit Claise' <bclaise@cisco.com>; 'Xufeng Liu' <Xufeng_Liu@jabil.com>; 'Mahesh Jethanandani' <mjethanandani@gmail.com>; 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
- Yangdoctors last call review of draft-ietf-teas-y… Mahesh Jethanandani
- RE: Yangdoctors last call review of draft-ietf-te… Xufeng Liu
- Re: [Teas] Yangdoctors last call review of draft-… Robert Wilton
- RE: [Teas] Yangdoctors last call review of draft-… Xufeng Liu
- Re: [Teas] Yangdoctors last call review of draft-… Robert Wilton
- Re: [Teas] Yangdoctors last call review of draft-… Benoit Claise
- RE: [Teas] Yangdoctors last call review of draft-… Xufeng Liu
- Re: [Teas] Yangdoctors last call review of draft-… Benoit Claise
- Re: [yang-doctors] [Teas] Yangdoctors last call r… Juergen Schoenwaelder
- RE: [Teas] Yangdoctors last call review of draft-… Xufeng Liu
- Re: [Teas] Yangdoctors last call review of draft-… Benoit Claise
- Re: [Teas] Yangdoctors last call review of draft-… Robert Wilton
- RE: [Teas] Yangdoctors last call review of draft-… Xufeng Liu
- Re: [Teas] Yangdoctors last call review of draft-… Mahesh Jethanandani
- Re: [Teas] Yangdoctors last call review of draft-… Mahesh Jethanandani
- RE: [Teas] Yangdoctors last call review of draft-… Xufeng Liu