Re: [netconf] [netconf-wg/https-notif] Should the receivers container be moved under the augment statement and the leafref renamed? (#2)

Kent Watsen <kent+ietf@watsen.net> Tue, 11 February 2020 15:26 UTC

Return-Path: <0100017034db6704-09a8b95c-654c-4a99-9a08-31f94e265b9e-000000@amazonses.watsen.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 CF771120170 for <netconf@ietfa.amsl.com>; Tue, 11 Feb 2020 07:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 D7pRtlJMObNG for <netconf@ietfa.amsl.com>; Tue, 11 Feb 2020 07:26:00 -0800 (PST)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F64E120164 for <netconf@ietf.org>; Tue, 11 Feb 2020 07:26:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581434759; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=PnwOYWrpDLWsYVGK8UXZOt1KD9BD1xE8IduN8jAswJI=; b=Zvy5404eki1UPvDldGzblyPYp+q/xxHiKmbzp9qvYRQ4AHHULif4N0bP0o3GkGcw JGhGU9JhIG1lHzZYROC7i44IMJ57tZuANjMxSGrvZt0eQXimygzDOe5nwt7vo/8yRaD 18Z2jtHix64I8nlu+Jb6x873hahOU/eEtYYU1Le0=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <20200211.142456.1627117725994673253.mbj@tail-f.com>
Date: Tue, 11 Feb 2020 15:25:59 +0000
Cc: "netconf@ietf.org" <netconf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <0100017034db6704-09a8b95c-654c-4a99-9a08-31f94e265b9e-000000@email.amazonses.com>
References: <netconf-wg/https-notif/issues/2/555352822@github.com> <20191119.161851.678459934233941550.mbj@tail-f.com> <0100016fa69f59c6-212e569d-fb2b-47cb-a1ff-e897829ba111-000000@email.amazonses.com> <20200211.142456.1627117725994673253.mbj@tail-f.com>
To: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.02.11-54.240.48.94
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/_gfDHNX77HldSaPF3xxS2xqKsOE>
Subject: Re: [netconf] [netconf-wg/https-notif] Should the receivers container be moved under the augment statement and the leafref renamed? (#2)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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: Tue, 11 Feb 2020 15:26:02 -0000

Hi Martin,

>>>> The reason to not move the receiver container under the augment is so
>>>> as to allow the leafref to point to multiple receivers.
>>> 
>>> I don't understand this reason.
>> 
>> Each "receiver" (in https-notif) maps to an HTTPS connection from the
>> publisher to the receiver.
>> 
>> There is likely to be more than one configured subscription, yet all
>> notifications should go to the same receiver.
>> 
>> We'd like to use the same HTTPS "connection" for all, as opposed to
>> having an HTTPS connection for each.
>> 
>> The "receiver-ref" leaf provides an indirection enabling this
>> many-to-one relationship.
> 
> I can't find the original thread about this issue, so I'll rephrase
> what I (think I) wrote from the start:
> 
> I understand the reason for the many-to-one, and I wish we had that in
> the base model itself (i.e., RFC 8639), so that protocol-documents
> didn't have to invent this, and so that we could have
> receiver-specific config in one place.

I agree, it would’ve been better in RFC 8639.  I recall Juergen writing once that he expected it to be a common pattern.  But that is behind us now, or are you suggesting a -bis?  Is there is an action coming out of this fork in the thread?


>>> Since this is not a stand-alone model, I think it should augment
>>> /sn:subscriptions.  In some way it doesn't matter what nodes are
>>> called and where they are located, but having descriptive names and
>>> keep related nodes under common subtrees helps the understanding of
>>> models.
>> 
>> Is s/receiver-ref/https-receiver-ref/ what you had in mind?
> 
> Yes, as a minimum.
> 
> I would also change the top-level container "receivers" to augment
> /sn:subscriptions:
> 
>  augemnt /sn:subscriptions {
>    container https-receivers {
>      ...
>    }
>  }

Ah, I see now, thank you for providing the snippet.


Kent // contributor