Re: [netconf] https-receiver in draft-ietf-netconf-https-notif-02

Qin, I think Reshad’s question regards YANG modeling.

Reshad, are you suggesting that a pattern will evolve over time and can we prep for now?  This would be consistent with statements made by Juergen and Martin in the past, i.e., that 1) the desire to have many subscriptions point to the same receiver transport is going to be common and 2) it’s too bad RFC 8639 didn’t consider this (*).

If I understand correctly, you’re suggesting the creation of another module (“new-module” in tree diagram below), independent of https-notif, that only defines a list of receivers, with just a “name” key node and a “receiver-type” choice node in which “notif” transports (e.g, https-notif) could augment a receiver into.  Something like this?

 module: ietf-subscribed-notifications
    …
    +--rw subscriptions
        +--rw new-module:receivers
            +--rw receiver [name]
                 +--rw name                                 string
                 +--rw (receiver-type)
                      +--rw https-notif:https-receiver?
                           ...
        +--rw subscription* [id]
            +--rw receivers
                +--rw receiver* [name]
                    +--rw name                      string
                    +--rw new-module:receiver-ref?   leafref -> /subscriptions/new-module:receivers/name

(*) Please recall that the WG “consensus" was to move forward with “configured” subscriptions even though we had no configurable “notif” transport at the time.  Some were concerned about what we were not thinking about things, such as this issue, as well as the multi-steam originators “channel” issue.   IIRC, the authors said that they would walk away from the draft if the WG removed “configured” subscriptions while urging the WG to move faster.

Kent // contributor

> On Apr 6, 2020, at 12:49 PM, Qin Wu <bill.wu@huawei.com> wrote:
> 
> 
> In telemetry data transport capability draft, we allow server to advertise multiple transport protocol, encoding, the client can specified transport and encoding in the yang push subscription model and select appropriate transport from
> Sever supported transport protocols.
> 
> 
> 
> 发件人： Reshad Rahman (rrahman)<rrahman=40cisco.com@dmarc.ietf.org>
> 收件人： netconf<netconf@ietf.org>
> 主题： [netconf] https-receiver in draft-ietf-netconf-https-notif-02
> 时间： 2020-04-07 00:24:53
> 
> Hi,
> 
>  
> I understand why nodes receiver(s) were renamed to https-receiver(s) and moved to SN.
> 
>  
> So is the plan to have different receiver lists for each transport (assuming we’ll have multiple transports)? Why not have 1 receiver list (keyed on name) and add protocol specifics as needed? If this was already discussed, apologies for beating a dead-horse.
> 
>  
> Regards,
> 
> Reshad.
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf