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

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 6 Apr 2020 16:24:03 +0000

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.

---

From: Qin Wu <[email-masked]>
Date: Mon, 6 Apr 2020 16:49:08 +0000

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=[email-masked]<mailto:rrahman=[email-masked]>>
收件人： netconf<[email-masked]<mailto:[email-masked]>>
主题： [netconf] https-receiver in draft-ietf-netconf-https-notif-02
时间： 2020-04-07 00:24:53

Hi,

Regards,
Reshad.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 7 Apr 2020 14:50:23 +0000

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 <[email-masked]> wrote:
> 
> 
> 发件人： Reshad Rahman (rrahman)<rrahman=[email-masked]>
> 收件人： netconf<[email-masked]>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 7 Apr 2020 18:28:33 +0000

Hi Kent,

On 2020-04-07, 10:50 AM, "Kent Watsen" <[email-masked]> wrote:

    Qin, I think Reshad’s question regards YANG modeling.
<RR>Correct. I took Qin's answer as "yes we will probably support multiple transports".
    
    Reshad, are you suggesting that a pattern will evolve over time and can we prep for now?  
<RR> Yes I am.
    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?
<RR> Yes, the receivers being in a transport-agnostic model as you have below. As for the transport-specific properties, my first thought was to have augmentations for these but what you have below seems to work. An initial question is whether we'd want to reuse receivers for multiple transports, I guess we need to figure out the use cases.
Also, I believe we should try to avoid having certain shared properties (IP address?) in multiple places/transports.

Regards,
Reshad.

    
    Kent // contributor