Re: [Netconf] YANG Doctor question: empty mandatory choice?

Kent Watsen <kwatsen@juniper.net> Thu, 02 August 2018 15:12 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 381C6130EA1 for <netconf@ietfa.amsl.com>; Thu, 2 Aug 2018 08:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] 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 OasHppSbl9AT for <netconf@ietfa.amsl.com>; Thu, 2 Aug 2018 08:12:00 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 B6868124C04 for <netconf@ietf.org>; Thu, 2 Aug 2018 08:12:00 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w72F4RwK029433; Thu, 2 Aug 2018 08:11:57 -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=7nmQ6sLH3yDN/utOymrvGGni5bcU7D4e3wX7+QQHF8w=; b=Qz7Z1dPS7YlkoFpVodo8Gd6m78ni9i6xpTLVl7r96o+yr76uHaSueZ/vR0G4WphrFf3h 02u2PMGsaO1alOxPDx8MiP0V+UPnTDvc8xCE5xJjiFpSsaH8I7qbw3yWe0aNSA1MUzf3 5roLqgjXpAnoV3fCF5RxXr6vHEmFsEwJOA6QuQPxJK87p8CC5W/yumtxLbt8xwGwsevM aDO2spwgmoOqyk6tYkilE0NxUnHzkf5yAkVPSXYy9vd2OPYgKsVW22KyKl510B7WVOpg PIb4R5LQofv0xISp3Q9I9HVYnLcBUbObPtwt740jtFBO550FWGVqwM3HqefduVm9eEIW rw==
Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp0112.outbound.protection.outlook.com [216.32.180.112]) by mx0a-00273201.pphosted.com with ESMTP id 2kkwjtgq4k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 02 Aug 2018 08:11:57 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB3994.namprd05.prod.outlook.com (20.176.71.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.8; Thu, 2 Aug 2018 15:11:54 +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.003; Thu, 2 Aug 2018 15:11:54 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Alexander Clemm <alexander.clemm@huawei.com>, Martin Bjorklund <mbj@tail-f.com>
CC: "evoit=40cisco.com@dmarc.ietf.org" <evoit=40cisco.com@dmarc.ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] YANG Doctor question: empty mandatory choice?
Thread-Index: AQHUKEYUmUSBX283/kCJ9HawSKyfbKSpa0GAgABGJoCAAqFHAA==
Date: Thu, 2 Aug 2018 15:11:54 +0000
Message-ID: <024DE375-E3F0-4255-AC53-2D17C77D6E06@juniper.net>
References: <44B0A74E-CCF0-4E9B-846A-1F46E90AEB5E@juniper.net> <20180731.165103.950825344221422538.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB406AA@sjceml521-mbx.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB406AA@sjceml521-mbx.china.huawei.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.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB3994; 6:ffl05vXLMhvD6bGvjgzz/C93jXCx8+3X88PPFFtR65dcC65f3/KQ14u0JocAtV+OURO1RaiDyFuKY0okg5tA7B4sq7OxGzHZc1lNwFKhO1Vbc7mzxsBV4l2mtYTylZrfdgLjfsNt/yQQaMmgb1O1iljeO5GP3lRbhLJwDjFQf4C6syZImPUNEpc5G+OIJMNpnFHFeixJbt15v4NZ+E6kKeblGnBBzQLf+egWuMqPjhUdvuTY/r6PaVgXtg4jf+KejUrLa5Z7O3HlzLf4G7ZNR7bzSXO++xskIfsQjvY2YhgVNG0qsRIGDcq5GkgL8cgCWpg66cO/fO2296pgjlr2Cfb/oVGueOoPQorX0GSkT4p42U8uNVgsvLNlsJC4txb2Vmg/44stAD/60O6InVSIHnv6MUhhVtEYI60k1HzcdJt3AIslIGWmsRb0pPF0EYDAx/7u7Rk+dSlLmiSdaxSMtw==; 5:tPs2vCQXiLgL4Cin+o5tucm9GflwTiTK2pNdQGnidAthHoEL8hJLd2VPghJjKmXBzix/bbbE8trBUfGkOyRJUsbNqax1NKRaW1X1YtLmo1rqn51Z+X9LCdB2Vt49Yt2mxsYqynyOC3jtQlPAwS3OL99O+yp4NYUS1egNIhHVoLQ=; 7:6ZmI/jGe2dgQgg5dI2FsOks0YM+qJ9LOcvBoOsGUM/mCN9QF5rvCI8UQqwxgbDaQ41NL0/n86z8+xbcz848Z+iArgCowdAjsQyaW8qsRB3hmMNbWVU0Vbg/083RqWl2GRn4zN8RstKo01/3wA3PsQTCxTiTQjg+PNFlxyemycg0LSM1/QuHR8GGy8B8lSBLBmZT1Byu4nFoPmUJvetBWEaOOTa5DFRbNHyOcvDef4t7eXT6/dinuFVrr6+xUViVl
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 5a1962ac-a7e4-48a0-7d1b-08d5f88a487c
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:DM6PR05MB3994;
x-ms-traffictypediagnostic: DM6PR05MB3994:
x-microsoft-antispam-prvs: <DM6PR05MB39945C9C59D002C00E0F5BFEA52C0@DM6PR05MB3994.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(138986009662008)(10436049006162);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DM6PR05MB3994; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB3994;
x-forefront-prvs: 07521929C1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(136003)(396003)(13464003)(51444003)(199004)(189003)(6436002)(6246003)(2900100001)(6486002)(81166006)(575784001)(81156014)(8676002)(25786009)(4326008)(7736002)(229853002)(305945005)(8936002)(6506007)(256004)(3846002)(102836004)(6116002)(76176011)(53546011)(26005)(6512007)(14444005)(5250100002)(86362001)(83716003)(6306002)(53936002)(316002)(82746002)(110136005)(58126008)(68736007)(99286004)(54906003)(36756003)(66066001)(97736004)(106356001)(2906002)(33656002)(446003)(11346002)(186003)(966005)(486006)(476003)(478600001)(2616005)(105586002)(14454004)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB3994; 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: RWekSH3y/jG2RObQSphVod+own+XNLwm7u32C0t2fFKh8Cyne7ZJGUrJ3+ksGQM/N4IB+fYPWlLb6HfGa+/qa6sjBFz5cExyPewVE5QiJl8BR2jOMQr/Ytk4TCwgplsvJRm9nz44vs7mHyzaSU4Iub01PkdNLXZLjQe3ZqrHAbfQbYj1bYrrgoWzKF2uEpfCKDpPdvwW+jvqbYaATMCrFfK+jR8bDrJ1caAvwzUVBe7WHpbusg6P/7R+mK0K+wf4jihiT+oONp+D1tDXxh1hb9Lg1x7n4JzXDlgN6nitXRROQZmsKHuNolB/SZ10L6QAC9vbYqLwyWxfIhvZ6VzHjrip7xXeqQm+53p6/sVN3gc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <12464BBF9E3E5748B2C4BF796C5F6424@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a1962ac-a7e4-48a0-7d1b-08d5f88a487c
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2018 15:11:54.7526 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB3994
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-02_03:, , 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-1806210000 definitions=main-1808020156
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/cTCv_fTqu1ZQBlugSAp5SYhs7kA>
Subject: Re: [Netconf] 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: Thu, 02 Aug 2018 15:12:04 -0000

I am sympathetic to Eric's and Einar's observation that a given subscription, having multiple receivers, is likely to have all the receivers using the same transport and encoding.

The thought behind this is that, assuming there are multiple distinct applications, each application will selfishly create its own subscription; it will not try to see if there is another existing subscription that matches its needs.

Thus, in effect, the *only* purpose for there being a *list* of receivers is for enabling high availability, which I think is okay.  I wish the text was clearer about this objective.

What I object to is the way that this restriction is currently implemented using identities, which requires the "notif" models to do something right.  Better would be a "must" expression that says the count of the descendants is exactly one.  Can you do that?

Kent // contributor


===== original message =====

I am wondering why we are reopening the issue of multiple encodings/transports per receiver vs per subscription?  

Having single transport / encoding per subscription is a simpler design (feedback from implementors; simplifies dealing with any error conditions due to encoding that would affect one receiver but not others in the same subscription; Einar has explained this in the past) and, while I am in general a fan of general design, there does not seem to be business requirements and scenarios that demand this - and even if there were, this would constitute merely an optimization (since if you have different receivers who want different encodings/tranport, you can always simply create another subscription).  

If in the future there is really desire to add this as an additional feature, we can put this into a -bis version.  (Adding stuff will be easier than taking things away.)  Let's just be done.  

--- Alex

> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin
> Bjorklund
> Sent: Tuesday, July 31, 2018 7:51 AM
> To: kwatsen@juniper.net
> Cc: evoit=40cisco.com@dmarc.ietf.org; netconf@ietf.org
> Subject: Re: [Netconf] YANG Doctor question: empty mandatory choice?
> 
> Kent Watsen <kwatsen@juniper.net> wrote:
> > [removing yang-doctors list, and updating subject line accordingly]
> >
> >
> > >> > Why do all receivers of a subscription have to use the same
> transport?
> > >>
> > >> This was something that Martin and Eric worked out before we did
> > >> the first Last Call.  Eric doesn't seem to know the particular
> > >> reason, other than Martin seems to think it’s easier.
> > >
> > > No; I personally also prefer a design where each receiver has its
> > > own transport + encoding.
> >
> > +1
> >
> >
> > > The original model had a common "encoding" for all receivers, and
> > > then a receiver-specific transport - I think this is even worse,
> >
> > Agreed.
> >
> >
> > > and suggested to have transport + encoding defined together
> > > preferrably receiver-specifc or else common for all receivers.
> > >
> > > If the WG now believes that the transport + encoding should be done
> > > per receiver, this should be fairly easy to change.
> >
> > I also prefer per receiver, and I think that doing so will simplify
> > the model, as neither the mandatory "transport" nor the [not
> > mandatory?] "encoding" leaves have to be specified.
> >
> > In particular, my thoughts are that the "notif" model should provide
> > for the encoding selection, if needed (it's not needed for NETCONF, or
> > COAP I imagine).
> 
> I agree.  I think this would be a cleaner design.
> 
> 
> /martin
> 
> 
> >
> > In the case of RESTCONF, we could update the ietf-restconf-client and
> > ietf-restconf-server models to include an "encodings" leaf-list, to
> > configure the RESTCONF server which encodings it should support.  We
> > likely need to do something similar to configure which HTTP versions
> > should be supported.  Now, in a general RC server, the server could
> > support both but, if the restconf-notif draft has its own list of
> > restconf-servers (i.e., it uses the "restconf-server-grouping" itself,
> > see my July 19 email for a YANG example), then a constraint could be
> > added limiting the number "supported" to just one.  Thus, when the RC
> > server reboots, and connects to the receiver and *automatically* (no
> > client RPC) starts pushing notifications, it can know what encoding to
> > use.
> >
> > I'm still unsure if its legal for an RC server to automatically push
> > notifications without a client-initiated RPC of any sort, and I'm also
> > uncertain if supporting *configured* subscriptions for NC or RC is
> > needed (see my message July 20 email).  So, some of this may work
> > itself out as we progress.
> >
> > I know that we're not defining the *configured* notif drafts in this
> > first effort, the we are publishing the SN draft with a configuration
> > model, my only concern now is configuration model presented in the SN
> > draft.
> >
> >
> > Kent // contributor
> >
> >
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=Mh0UuTFvh9TpmFzzMMON07C4WQIwjRJLM-OT62OJZe4&s=PPy3uCUVVJa-GwAfmUexA9cX31IWHhlMHlAGMcPdnyY&e=