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

Juergen Schoenwaelder <> Fri, 27 July 2018 16:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FA3A128BAC; Fri, 27 Jul 2018 09:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gNGrV3VwSpJ1; Fri, 27 Jul 2018 09:15:19 -0700 (PDT)
Received: from anna.localdomain ( [IPv6:2001:638:709:5::7]) by (Postfix) with ESMTP id 265BE130F8E; Fri, 27 Jul 2018 09:15:19 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id D716E239B7EF; Fri, 27 Jul 2018 18:15:17 +0200 (CEST)
Date: Fri, 27 Jul 2018 18:15:16 +0200
From: Juergen Schoenwaelder <>
To: "Eric Voit (evoit)" <>
Cc: Robert Wilton <>, "" <>, "" <>
Message-ID: <>
Reply-To: Juergen Schoenwaelder <>
Mail-Followup-To: "Eric Voit (evoit)" <>, Robert Wilton <>, "" <>, "" <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: NeoMutt/20180716
Archived-At: <>
Subject: Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: YangPush now)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Jul 2018 16:15:21 -0000

On Fri, Jul 27, 2018 at 03:33:05PM +0000, Eric Voit (evoit) wrote:
> I am sympathetic to the possibilities.  There are some very cool modeling variants here.  Still, per the original thread "YangPush now", a current business objective is to see if we can conclude something with current drafts/scope.  As a single transport was the chosen consensus at and after IETF 100, going down this path would reopen some scoping discussions.   Note: for historical reasons, the discussion can be listened to at:
> (Note: that starting at 57 minutes, you and others voice a preference for 'single' due to simplicity ;-).  Also in the recording, you can year me recognize Martin's unvarying position that encoding and transport be both the subscription level, or both be at the receiver level.  I.e., I don't see how this gets reopened, and we close soon.)

Still looks like a CLR and somewhat odd once you use a choice for the
transports of a receiver (using a choice likely was not yet proposed
back then).

Looking at the draft-ietf-netconf-subscribed-notifications-14.txt, how
do the states of a receiver work with multiple transports? It seems
some text in the draft kind of assumes that a receiver has a single
transport. It seems dynamic subscriptions always have just one
associated transport. Configured subscriptions apparently can have
multiple with some constraints and it is unclear how the configured
subscriptions states work with multiple transports.

I am not sure if I understand things right but it seems to me that a
subscription can have multiple receivers and every receiver can have
multiple transports. Perhaps simplifying this to 'a subscription can
have multiple receivers and every receiver has a single transport
(like in the dynamic subscription case) and there are no constraints
on the type of transports used by the different receivers' gives you a
model that is less complex, easier to clearly define (the state of a
receiver becomes simpler to derived from a single transport state) and
the model likely still does everything that is practically needed.


Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <>