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

Martin Bjorklund <mbj@tail-f.com> Sun, 29 July 2018 15:41 UTC

Return-Path: <mbj@tail-f.com>
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 A7045130E69; Sun, 29 Jul 2018 08:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 SnbMRGAaSl1y; Sun, 29 Jul 2018 08:41:15 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E6F09130E6D; Sun, 29 Jul 2018 08:41:14 -0700 (PDT)
Received: from localhost (h-155-4-133-90.NA.cust.bahnhof.se [155.4.133.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 1DFF01AE018A; Sun, 29 Jul 2018 17:41:14 +0200 (CEST)
Date: Sun, 29 Jul 2018 17:41:14 +0200 (CEST)
Message-Id: <20180729.174114.96329883777062758.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: j.schoenwaelder@jacobs-university.de, evoit=40cisco.com@dmarc.ietf.org, yang-doctors@ietf.org, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <52EFF12D-DC75-49C2-B887-FB2450616A4C@juniper.net>
References: <727ae35abd394a85812168615acce2d3@XCH-RTP-013.cisco.com> <20180726221120.bv3mtlitoqqov2zm@anna.jacobs.jacobs-university.de> <52EFF12D-DC75-49C2-B887-FB2450616A4C@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/PsFGeYDyJo9NahdVfQkBl8fkg9I>
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: Sun, 29 Jul 2018 15:41:18 -0000

Kent Watsen <kwatsen@juniper.net> wrote:
> 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.

No; I personally also prefer a design where each receiver has its own
transport + encoding.  The original model had a common "encoding" for
all receivers, and then a receiver-specific transport - I think this
is even worse, 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.


> 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


/martin