Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice?
Kent Watsen <kwatsen@juniper.net> Mon, 06 August 2018 17:03 UTC
Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921D8130E58; Mon, 6 Aug 2018 10:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 bm4--aT0dEct; Mon, 6 Aug 2018 10:02:58 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33752130E23; Mon, 6 Aug 2018 10:02:57 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w76GxYgj010879; Mon, 6 Aug 2018 10:02:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=IxLXH5op2Rig3/bDu02kZU9poYB4jNmEnCvPqoZh5Kw=; b=c276i9hW8Up57mVAKAR/dDMN3wzdIjg8fMSmgqReS5sQSb3Jm7Luf01YgQjFvw3+C60a /0lQKjx9UfcYN6wkAgAf74i/baICCtLeKWwycHiQ7G1LL+u2ChhhWnJKeYYvA3rU4hKJ vKtUfBusMyFuAnsZexyNLoOWv9umw4QWeidSCO5IfNAZMCE2WPo5iQPH4ywh5FqqPR9S IIbQzYPf1J/wdiiyYfITwsOpUgeU9NAzoKwXPP6Jgab1DwudIlELIin78IuR+oCHhf3W UBwiy9S6xUCfo/ltM8nz9Kb4FcvYOmBJT+2d1DW31WeZVYwSaNq3Ygg+v0DC2TghoEmq 7g==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0054.outbound.protection.outlook.com [207.46.163.54]) by mx0b-00273201.pphosted.com with ESMTP id 2kppa4gjkx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 06 Aug 2018 10:02:53 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4026.namprd05.prod.outlook.com (20.176.71.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.14; Mon, 6 Aug 2018 17:02:51 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::e0bc:6a82:571d:258]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::e0bc:6a82:571d:258%2]) with mapi id 15.20.1038.019; Mon, 6 Aug 2018 17:02:51 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>, "rwilton=40cisco.com@dmarc.ietf.org" <rwilton=40cisco.com@dmarc.ietf.org>
CC: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice?
Thread-Index: AQHUKbd2gxK9WoMf0kWoD5voFWQc9qSw5SCAgAHS/oA=
Date: Mon, 06 Aug 2018 17:02:50 +0000
Message-ID: <F26138DC-A5B6-4EC6-AEDE-2F94DD1A3B7E@juniper.net>
References: <05ee68cd-ccc0-6803-6c71-b3952ee5608d@cisco.com> <CABCOCHRtg9jB0=b5bPPT3MS0QJcwgAY24Fg0RewXhPMR8Y+O0w@mail.gmail.com> <958669b9-c523-3c43-eca4-fbc255fc1bc8@cisco.com> <20180805.111123.2123994471181114333.mbj@tail-f.com>
In-Reply-To: <20180805.111123.2123994471181114333.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4026; 6:VvK9IgVdM7mVc+W9o/Nxbk2YCM5BYXgpM0aBjrvctZmV9RGPBmH7Rep+K8VpVZ9hu+lY/NXBfPz2E9a/1rPfTv/BOujkd2UEDqKSoZIT5UugpvMir9m3gBhoJlnlqXzu42hveD4eT4wSE5E/n4SRGDLOt0129TnmQFABUnzurxUZGHu77i61fYCtra3zLdyIDLjDq0K+e+2orNlW8DQOBtF9/uvgfjFpoCh5/K4kmeN7/Pqi0IoEisrcSUJJ0r4XACnsFIaXy5aM/CVO9cHoOoMXgy91+pWornTYFO4r19pSqBSdJRF7+f9rgc1d2TmFsF/ycGqTLYgnCazYMsx/f+GCdlBbhNAC8CfeBwr4CRAURyFmMuNbSqbYaofAn0ujAqDnARdF3qdmzD096i7Ys7ev7zLzfZ1l4ql3ZpuoM5eHqTy01M7DjPTx5M+2MfmZaM2ZTI8NuY5NaPATF57Z9w==; 5:Km92KlAL6tNUAj5lOsMf3Zhx0v1eTyp+4slJ+aEfD0xs9rY6W7S7E24ZAHXLg0FKf5GeH+vxR2s6QFjOl1sXiJK1cXsl8QfBKCDTxVYOstnslM1A1kW4i3P9dFOotWOBXfM5p+2YiMt0j/IHzeglGDFm/I3ZT5+5CQ/6waCZQqI=; 7:o5TXBxkFdenX2tjMflKCDo/MDRtliLoJ/ddqc/bTPmH2ppt2lmbapWA3fSlVImJFVWZkJ4bv2RTWRqkSiLmHmd6H7O/zVJdM3Ndjf8KpJB2BRjOF1AB54OUy6MsWzKuOr2Dy2Gs/HEvWqpkgFOE04OKbf6g5s1ma6A1g5yHhcszVMMBhGHtAPweyZ1xurVdefaCyEHi8qRRCmGEG/NnxGsWsof8/J8fmiL4NX3lYIiZOIWCA1KbE0YulCYi86PNt
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 6d21b4ab-c1a9-44d4-c2a8-08d5fbbe7197
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4026;
x-ms-traffictypediagnostic: DM6PR05MB4026:
x-microsoft-antispam-prvs: <DM6PR05MB40262A6C3AFE07281B99C5B0A5200@DM6PR05MB4026.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(100405760836317)(95692535739014);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DM6PR05MB4026; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4026;
x-forefront-prvs: 07562C22DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(396003)(136003)(366004)(199004)(189003)(51444003)(316002)(6512007)(6306002)(7736002)(6436002)(476003)(5250100002)(229853002)(575784001)(6486002)(86362001)(6246003)(486006)(25786009)(4326008)(82746002)(110136005)(36756003)(99286004)(58126008)(305945005)(54906003)(256004)(2900100001)(14444005)(53936002)(2616005)(26005)(966005)(561944003)(6506007)(53546011)(8936002)(76176011)(102836004)(97736004)(105586002)(81156014)(81166006)(5660300001)(478600001)(8676002)(83716003)(33656002)(14454004)(2906002)(93886005)(66066001)(446003)(6116002)(3846002)(11346002)(186003)(68736007)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4026; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: KjK4OhvU4ghKwVQKXp4Y+/JwhdnYppHAvbvcV2eoSP/7vzTYKHrR+O0EoPqMudkcvfgubFppi7kv5uPuRLg5ARsfi6ox/lY5Z9zGuIqv1TcuDfuIMCru1vxGuN+QlJMmH68hCsi/KR7bMe10DCl/t+hysnE7TrnrO2awNsD3OOfpdcYejaLYLCEGSwgMKl91nLY4m9f1/CJlz85KH7sdtDbaFTwhvgQNDRztZQ8ee9rqHV7fjg2YwhNC53uebsFOK1wve299R/Vu6WFE2Sg9oE6nlHcRAIMCHuboC31QPQvoACoF9tEM4JSOsAhOyRgAJtMDaSR7g1edUT4mEM+12UVn2vZdUn+Uxig26YwBF6U=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <D8F50709CD3F8E4C9F8A12832C3BC2D7@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 6d21b4ab-c1a9-44d4-c2a8-08d5fbbe7197
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2018 17:02:50.9131 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4026
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-06_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808060176
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/iSnDEokoyBjopr252qTvPbdKkUM>
Subject: Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2018 17:03:03 -0000
[top-posting for lack of time] Hi Martin, Interesting that you view the "transport" leaf as where the decision is made. I suppose that is the case now, but I always viewed the leaf as a somewhat artificial "anchor" that was added only to support the "when" expression to assert homogeneity. The On that, note that I merely said that I was sympathetic to the POV; I'm not convinced that there is a problem allowing heterogeneity, as what's been posted thus far for why it might be a [performance?] problem was conjecture. A fully cooked example would be helpful here, but I think you want: <receivers> <receiver> <name>foo</name> <ex:param1>...</ex:param1> <ex:param2>...</ex:param2> <ex:param3>...</ex:param3> </receiver> </receivers> whereas I was thinking that there would be a container, e.g. <receivers> <receiver> <name>foo</name> <ex:udp-pub-sub> <param1>...</param1> <param2>...</param2> <param3>...</param3> </ex:udp-pub-sub> </receiver> </receivers> which acts as the transport-selector, and hence homogeneity (if needed), could be via a "must" expression that ensures that there is only one such descendent, other than "name", across the receivers. This is what that "must" expression I proffered last week was trying to do. If we can do this, I think the model simplifies, as then the [artificial?] "transport" and "encoding" leaves, and the "when" expressions, wouldn't be needed to still assert the homogeneity. Thoughts? Kent // contributor Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org> wrote: > > > On 01/08/2018 17:09, Andy Bierman wrote: > > > > > > On Wed, Aug 1, 2018 at 9:01 AM, Robert Wilton <rwilton@cisco.com > > <mailto:rwilton@cisco.com>> wrote: > > > > > > > > On 31/07/2018 21:31, Andy Bierman wrote: > >> > >> > >> On Tue, Jul 31, 2018 at 12:39 PM, Eric Voit (evoit) > >> <evoit@cisco.com <mailto:evoit@cisco.com>> wrote: > >> > >> > From: Juergen Schoenwaelder, July 31, 2018 1:48 PM > >> > > >> > On Mon, Jul 30, 2018 at 08:41:42PM +0200, Martin Bjorklund > >> wrote: > >> > > > >> > > The empty mandatory choice does provide value since it > >> requires that > >> > > some transport-specific parameters are configured. > >> However, can we > >> > > assume that all transports require configuration > >> parameters here? > >> > > >> > Can you have a receiver without any transport parameters? > >> > > >> > > It is probably safest to not have a mandatory choice, and > >> instead > >> > > ensure that each transport augements the proper params -- > >> and since > >> > > this is YANG 1.1, the transport params that are augmented > >> can actually > >> > > be marked as mandatory. > >> > > >> > Frankly, an empty mandatory choice quite clearly says "this > >> is incomplete and > >> > unusable without an augmentation". > >> > >> My read above is the YANG doctor's position is that we should > >> *not* use the empty mandatory choice. Let me know if I got > >> this wrong. > >> > >> > >> I do not think a consensus call has been done yet, but I agree > >> with Juergen > >> and already raised the point that YANG conformance does not handle a > >> "MUST augment" use-case very well. > > I think that "empty choice + mandatory true" it is OK from a > > conformance perspective. The concept seems similar to an > > programmatic interface, abstract class, or even the abstract > > identity idea that has been proposed for YANG. If a server > > implements the module but no augments of the choice then it cannot > > be configured because the constraint will always fail. Andy, is > > your concern that tooling will warn that part of the model is > > unusable? > > > > > > That is possible. > > I agree with Juergen that a mandatory empty choice clearly indicates > > that the module is incomplete > > and unusable on its own. Is that a feature? > Yes, making that indication is the whole purpose of adding the > "mandatory: true" to the empty choice. Note, that I see that the > "mandatory true" is there to say that every configured subscription > must have a transport configured, which if true, doesn't seem > unreasonable. Note that the model already has a 'transport' leaf that is mandatory. The choice is an explicit placeholder for transport-specific additional parameters. This proposed design is slightly different than the design in ietf-interfaces; in interfaces we have: leaf type { ... } // type-specific augmentations here For example (from the RFC): augment "/if:interfaces/if:interface" { when "if:type = 'ianaift:ethernetCsmacd'"; container ethernet { leaf duplex { ... } } } In the notif model the proposal is: leaf transport { ... } ... choice transport-specific-params { // transport-specific augmentations here } Note that if the choice is not marked as mandatory, the resulting model will be less strict / useful compared to using a design like in the interfaces model (w/o the choice). To demonstrate, suppose we have a transport 'example-udp' that needs a mandatory 'address' and an optional 'port'. With the choice we'd have: augment '/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver' + '/sn:transport-specific-params' { when 'derived-from(../../../../transport, "ex:example-udp")'; case example-udp-params { leaf address { mandatory true; ... } leaf port { ... } } } If the choice is not mandatory, the model would allow a client to configure the transport leaf to 'example-udp', but not configure an address. Without the choice, we'd do: augment '/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver' when 'derived-from(../../../transport, "ex:example-udp")'; leaf address { mandatory true; ... } leaf port { ... } } In this case, or if the choice is mandatory, the model would require the client to configure an address if the transport is 'example-udp', which is what we want. But if the choice is marked as mandatory, *all* transports MUST define some transport-specific parameters, even if that is not needed (unclear if this will ever happen...) Thus, I prefer Eric's original model w/o the choice. The choice is supposed to be clever, but might end up being confusing, and I don't think it adds any value anyway. /martin > I.e. my main point is that I don't have an issue with > this generic YANG design. > > In this particular instance, I'm also fine if "mandatory: true" is > left out, but I don't really agree with writing the equivalent of > "mandatory: true" in the description, that seems like a poor > compromise. > > However, this is probably all bike-shedding. I think that any of the > discussed solutions is acceptable, as long as it is obvious to the > readers of the YANG modules that a case statement must be provided for > it to be useful, and I make the assumption that sane vendors won't > enable the "configured" feature, if there is no actual way of > configuring usable subscriptions. > > Perhaps Eric can propose his preferred choice, and we can see if > anyone still objects, otherwise maybe we can move on? > > Thanks, > Rob > > > > > > Andy > > > > > > I have to say that much prefer the option of putting "mandatory: > > true" in the choice than "MUST provide an implementation" in the > > description because the former is machine readable whilst the > > latter is not. > > > > However, I would also be fine not to have the "mandatory: true", > > but with the choice description to state something along the lines > > that the empty choice is to allow for augmentations of different > > transports, and configured subscriptions may not be usable unless > > at least one transport case statement is available." But perhaps > > some implementation will provide the flexibility of defining a > > single transport for all subscriptions (if this is feasible). > > > > One other observation that could affect the decision here is that > > YANG allows "mandatory: true" to be removed in a future revision > > in a backwards compatible way, but doesn't allow it to be added. > > > > Thanks, > > Rob > > > > > >> > >> I prefer the MUST be in the description-stmt for the choice, > >> instead of "mandatory true". (I prefer SHOULD but if the WG wants > >> MUST) > >> > >> > >> Andy > >> > >> > >> > >> That would mean that each transport document supporting > >> configured subscriptions would then augment transport > >> specific parameters to > >> "/subscriptions/subscription/receivers/receiver". And > >> (assuming the "single transport" decision of IETF100 isn't > >> changed), that the identity "transport" could be leveraged to > >> enforce that only a single transport specific set of > >> credentials are associated with a receiver. > >> > >> A sample YANG augmentation for NETCONF would then look like: > >> > >> module ietf-netconf-subscribed-notifications { > >> > >> prefix nsn; > >> > >> import ietf-netconf-client { prefix ncc; } > >> import ietf-subscribed-notifications { prefix sn; } > >> > >> identity netconf { > >> base sn:transport; > >> base sn:inline-address; > >> description > >> "NETCONF is used as a transport for notification > >> messages and > >> state change notifications."; > >> } > >> > >> augment > >> "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { > >> when 'derived-from(../../../transport, "nsn:netconf")'; > >> description > >> "This augmentation allows NETCONF specific parameters > >> to be > >> exposed for a receiver."; > >> leaf netconf-endpoint { > >> type leafref { > >> path > >> "/ncc:netconf-client/ncc:initiate/ncc:netconf-server" + > >> "/ncc:endpoints/ncc:endpoint/ncc:name"; > >> } > >> mandatory true; > >> description > >> "Remote client which need to initiate the NETCONF > >> transport if > >> an existing NETCONF session from that client is not > >> available."; > >> } > >> } > >> } > >> > >> Which results in: > >> +--rw subscriptions > >> +--rw subscription* > >> +--rw transport transport {configured}? > >> +--rw receivers > >> +--rw receiver* > >> +--rw nsn:netconf-endpoint leafref > >> > >> Eric > >> > >> > >> > /js > >> > > -- > >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> > Fax: +49 421 200 3103 > >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nvlGbzwaLflz8fPtIV-iMrmk_M-b_KUsBI5XkyR6OQA&s=HOUalUJdAOVqj49diEzGM-Z-35a5rPmj2Y4NfhsdovQ&e= > >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nvlGbzwaLflz8fPtIV-iMrmk_M-b_KUsBI5XkyR6OQA&s=HOUalUJdAOVqj49diEzGM-Z-35a5rPmj2Y4NfhsdovQ&e=>> > >> > >> > >> > >> > >> _______________________________________________ > >> yang-doctors mailing list > >> yang-doctors@ietf.org <mailto:yang-doctors@ietf.org> > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nvlGbzwaLflz8fPtIV-iMrmk_M-b_KUsBI5XkyR6OQA&s=O67dhIVon_08t5AfSaVuRD1q-v2D8tAoezbECOsGoHY&e= > >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nvlGbzwaLflz8fPtIV-iMrmk_M-b_KUsBI5XkyR6OQA&s=O67dhIVon_08t5AfSaVuRD1q-v2D8tAoezbECOsGoHY&e=> > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nvlGbzwaLflz8fPtIV-iMrmk_M-b_KUsBI5XkyR6OQA&s=8uwYVApwY6kkzVSQBhp7pYLX9cex7YQ35Dyymf1wK2o&e=
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] YANG Doctor question: empty mandato… Kent Watsen
- Re: [Netconf] YANG Doctor question: empty mandato… Andy Bierman
- Re: [Netconf] [yang-doctors] YANG Doctor question… Robert Wilton
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] YANG Doctor question: empty mandato… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Robert Wilton
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- [Netconf] YANG Doctor question: empty mandatory c… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] [yang-doctors] YANG Doctor question… Robert Wilton
- Re: [Netconf] [yang-doctors] YANG Doctor question… Robert Wilton
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] YANG Doctor question: empty mandato… Kent Watsen
- Re: [Netconf] YANG Doctor question: empty mandato… Kent Watsen
- Re: [Netconf] YANG Doctor question: empty mandato… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] YANG Doctor question: empty mandato… Juergen Schoenwaelder
- Re: [Netconf] YANG Doctor question: empty mandato… Alexander Clemm
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] [yang-doctors] YANG Doctor question… Robert Wilton
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] YANG Doctor question: empty mandato… Kent Watsen
- Re: [Netconf] YANG Doctor question: empty mandato… Andy Bierman
- Re: [Netconf] YANG Doctor question: empty mandato… Einar Nilsen-Nygaard (einarnn)
- Re: [Netconf] YANG Doctor question: empty mandato… Einar Nilsen-Nygaard (einarnn)
- Re: [Netconf] YANG Doctor question: empty mandato… Henk Birkholz
- Re: [Netconf] YANG Doctor question: empty mandato… Andy Bierman
- Re: [Netconf] YANG Doctor question: empty mandato… Andy Bierman
- Re: [Netconf] YANG Doctor question: empty mandato… Kent Watsen
- Re: [Netconf] YANG Doctor question: empty mandato… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] YANG Doctor question: empty mandato… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… tom petch
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund