Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?

["Eric Voit (evoit)" <[e-mail]>]

Hi Balazs,

From: Balazs Lengyel, November 15, 2017 12:01 AM


While I see no real need for different protocols for the same transport, I also any real reason to restrict this. I would vote for the draft to leave this to the implementations. Unless we have a good reason why make a stand pro or contra?

Let me try to reframe to make sure I have your points right...

As the question is only for configured subscriptions, some transport must be defined.  Otherwise the path to the receiver cannot be established.  If we leave it to the implementation, it would make more sense to allow for the configuration of transport on a per-receiver basis.  This way either method can be supported.  I.e., it looks like favors option (1).

IMHO if we or an implementation allows transport conversion it is still not guaranteed that no notifications are lost or duplicated.

If there is a single subscription, there are mechanisms available to address potential sources of duplication.  An example would be the "previous-notification-id" from draft-ietf-netconf-notification-messages.  With two subscriptions, there will be no such constructs, and duplication by definition will occur when both are configured.  So this also seems to favor option (1).

In case 2) will we would need to enforce the common transport in the model.

Yes.  Enforcing (2) would move the transport under the subscription rather than under the receiver.  This would preclude (1).   As your point above is that we shouldn't artificially constrain things here, this seems to be a vote for (1) over (2).

Thanks,

Eric

regards Balazs

On 2017-11-15 11:43, Eric Voit (evoit) wrote:

In the WG session tomorrow, I am hoping to get "hum feedback" on:



draft-ietf-netconf-subscribed-notifications

https://github.com/netconf-wg/rfc5277bis/issues/4



The two choices and their issues exposed during the two week review on "Can Transport vary across different receivers of a single configured subscription?" are:



(1) Yes, Transport can vary by receiver

*        Fewer subscriptions (scale benefit)

*        Can convert transport without requiring an application to learn a multiple subscription ids

*        No duplication of content during transport conversion.

*        (Potential confusion in allowing transport to vary, but encoding not to vary?)



(2) No, only one Transport across all subscriptions

*        Simpler model

*        But applications may need to create and track multiple subscription-ids for the same content.

*        Temporary duplication of content streams during transport change.



The current draft does (1).



Thanks,

Eric






_______________________________________________

Netconf mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/netconf



--

Balazs Lengyel                       Ericsson Hungary Ltd.

Senior Specialist

Mobile: [phone]              email: [e-mail]<mailto:[e-mail]>