Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: YangPush now)

Kent Watsen <kwatsen@juniper.net> Thu, 26 July 2018 23:30 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 E7AA1130DDB; Thu, 26 Jul 2018 16:30:40 -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 Q1a7qFUOe10A; Thu, 26 Jul 2018 16:30:38 -0700 (PDT)
Received: from mx0a-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 8290B131263; Thu, 26 Jul 2018 16:30:38 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6QNTDgA002018; Thu, 26 Jul 2018 16:30:37 -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=IquGg+aHsLfrk7pE1Fib7ittPByUfNLuxEPoAvOB1Zw=; b=FoWdeWWhEF7Pc9/HatYgQw3vd4QJ/XhBFlEOZD+llKY/gkf8V4sqpnosvyxvKE5mtkmA kHqGtooXPNMYzhwfp09v9oHg379qk6yq66Exx7SEj+GmM6iFZTI23B7h03wlslq2JSOh orDqk0lMjaDgrNwWxaZiqQw0vbCSgq40l83xQxP6I8d0FdZQ9pKnLzxw8UEdYgJd9/Ki A4IWmVzm58HtICkSTRRRxeyW+ZZnw26Qfu01Lgzz2Z7Ltb4scZYNKOZG412+qV00EL8a cqCN+D3on4WLVDXtuKHdW3Momzi9bFAD6smeRHCymcDIocntG4Z0hll3Jj1grwv2FZIi 9Q==
Received: from nam05-by2-obe.outbound.protection.outlook.com (mail-by2nam05lp0243.outbound.protection.outlook.com [216.32.181.243]) by mx0a-00273201.pphosted.com with ESMTP id 2kfh870rtg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 26 Jul 2018 16:30:37 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB3958.namprd05.prod.outlook.com (52.135.195.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.5; Thu, 26 Jul 2018 23:30:35 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::84c5:999c:9159:d416]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::84c5:999c:9159:d416%2]) with mapi id 15.20.0995.014; Thu, 26 Jul 2018 23:30:35 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>
CC: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: [Netconf] YangPush now)
Thread-Index: AQHUJS2bUZNQlr2Y60asVHOWAIbS96Sh4+MA
Date: Thu, 26 Jul 2018 23:30:34 +0000
Message-ID: <52EFF12D-DC75-49C2-B887-FB2450616A4C@juniper.net>
References: <727ae35abd394a85812168615acce2d3@XCH-RTP-013.cisco.com> <20180726221120.bv3mtlitoqqov2zm@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180726221120.bv3mtlitoqqov2zm@anna.jacobs.jacobs-university.de>
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; BYAPR05MB3958; 6:8L+3lEZAaspjDTUW/2zFo4+Khcb7WpIHJztYXmO8Erh7YlVMxWnqdG7gwxFscubCgEQroRdQbqasaFkq4+kdNx7UudPGLYSllOJRr/jaGuVBCxZ6A579zLyYsUpA47ckuKY578M1WBYxKTdMKfImgbpSXjb9q1D/+GaINzz2yEVgG61jF4wVAiTbeu2dsz5RtyIEfgAG4YHjKj74c1uw2kNpCQZukB1UthOmrIVPfM969GyFvpaXNmhmwckAVW3fZzICTQ6RXOMt5BWYwpkuY0nFWjxFJdIoRLsln+UnFmFSCYXR1SBmltVLrMCPdlnlxja4mzTynx0oaUpFlVSEI4NAqwfhZiU4O1pUBj0gJpnskWj8sBxxHHmtXn4UjAVjof9B4IrWoDwreYnuOhaU2h6Yz7Mme4Z/agQpFGVMzyUS1mecyx487MqLqkj9+ASHtvA9U8AntWuiU2TewSQkrQ==; 5:hNV0lDtWen9eYcpyKIKqRcRKJIqRi/cRxhmLsetL3kiZaqMuBpku3dlh1Qjx4tn0GklWdWAkUUaarO60scp+TFREwqIGyjoJvysugRMezBVYCnTUOPc+GWexhcUM9xttKTyIkwdGbrARpWwDxTVcTRRMPuHXJu35dYUZ9USYpHo=; 7:yjjqVaLZMVJJuFY++sCJqG3ZwBbRLNDJuXtcs/jQ/NtiIkjNWmCwMlDfT//vZROHNTCLTY/01e4P9jFOml8eg4fvYPcHwCmiBVDcG/Ci/uBWhDomkZfzc6D7HcDsiFwa/64qHRjlrqf9sIxI6AeSmqwF3QNmrL9FOb5M/Hbb53j2BTLYlH9fXBVbVFmdwyubj3DqO+sB0OR+MSKCx94Hnpq1ImbvtQJ37MGCZOAib7Fih5/Df+NYtc8ZRzKnHKOR
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: adf12fa4-888c-4e25-5061-08d5f34fc980
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB3958;
x-ms-traffictypediagnostic: BYAPR05MB3958:
x-microsoft-antispam-prvs: <BYAPR05MB3958484E412B8C83B740A462A52B0@BYAPR05MB3958.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB3958; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB3958;
x-forefront-prvs: 07459438AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(39860400002)(366004)(346002)(396003)(199004)(189003)(4326008)(36756003)(54906003)(5660300001)(58126008)(106356001)(8676002)(2906002)(81166006)(81156014)(316002)(3846002)(305945005)(6116002)(110136005)(68736007)(33656002)(105586002)(8936002)(7736002)(478600001)(14454004)(83716003)(6246003)(66066001)(11346002)(53936002)(446003)(6512007)(256004)(2616005)(25786009)(486006)(97736004)(2900100001)(5250100002)(476003)(14444005)(6486002)(82746002)(6436002)(229853002)(26005)(186003)(99286004)(76176011)(6506007)(102836004)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB3958; H:BYAPR05MB4230.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: 689lLZDvruJi5KBekMDfWfPoMMyDj9L3w+M34gqFOw4RX2hHcmC4gG/ErAdO7z07uoXBr/wgVL1o7DeXnejvxqEF/0hVslxPiAGh4KP+whhP1zbNWtNFYmNGvjcDkAP99Z0ZC82CyBIoiM72tpH7tJYeNy5rG187Ke9RgBW+SMI8XaZpEvVrBLVgWXbwoEmrP47lSniYSEgyykBV5eA+Wof1XUFvKnrMF52vgKB1WQlbTo/y1cDiLDLk5WiLxYUJDRNAa+b1EhXVc4IxPdmaysZ+UDVbbPKIvUn9ofht9A8fPhMwBxFuZEf8UXoB57HGggY/tFYc8qRHkks249TZLD/cHpdkpSn1+gcW9xu0d+4=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <D376C5A2482817479C7EE3F0D9986EB1@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: adf12fa4-888c-4e25-5061-08d5f34fc980
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 23:30:34.9513 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB3958
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-26_06:, , 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=1011 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-1807260236
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/23ZlZAjUuLoHfe-aQ8yfYErfoZk>
Subject: Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: YangPush now)
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, 26 Jul 2018 23:30:41 -0000

Hi Juergen,


> Why is the transport leaf needed if the choice cases identify the transport? 

My understanding is that this leaf is needed (exclusively?) to support the
enforcement that all the transports for a given subscription use the same
transport.

I've also been asking about this, partly from the "difficultly to enforce"
reason Eric mentions (though see the "when" statement in Eric's 7/20 email
where he resolves this, I thought), but also from a "are we making this
more difficult than needed?" perspective.


> 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.

Thinking out loud, I can sort-of, but not really, understand the motivation
for wanting to enforce the same encoding (xml, json, etc.) across receivers
and, since some transports may require certain encodings (i.e. netconf-->xml,
coap-->cbor, etc.), it carries that the transports should be the same too?

What I don't like about this argument is:

1) It's not user-friendly.  If a server really does have to send similar 
   subscriptions to a set receivers using different transports and/or 
   encodings, we've introduced what looks like an artificial need to 
   duplicate the subscriptions for each unique transport+encoding 
   combination.

2) I don't understand the implementation issue.  My view is that slightly
   clever code that caches encodings used could do this in one loop.  
   Here's some pseudo-pythonic code:

   send-notification-to-receivers(receivers, native-notification):
     xml-notification=None
     json-notification=None
     for receiver in receivers:
       if receiver.encoding is XML:
         if xml-notification is None:
           xml-notification = to-xml(native-notification)
         receiver.send(xml-notification)
       if receiver.encoding is JSON:
         if json-notification is None:
           json-notification = to-json(native-notification)
         receiver.send(json-notification)

   
Kent // as a contributor