Re: [Netconf] subscription-id management across applications

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

From: Andy Bierman,  July 9, 2018 1:26 PM

On Mon, Jul 9, 2018 at 9:49 AM, Robert Wilton <[e-mail]<mailto:[e-mail]>> wrote:

On 09/07/2018 17:34, Andy Bierman wrote:


On Mon, Jul 9, 2018 at 9:31 AM, Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>> wrote:
On Mon, Jul 09, 2018 at 09:12:57AM -0700, Andy Bierman wrote:
> Hi,
>
> The configured subscriptions use a uint32 subscription-id.
> There is text in 5.2 about splitting the range for dynamic and configured
> subscriptions:
>
>    To support deployments including both configured and dynamic
>    subscriptions, it is recommended to split subscription identifiers
>    into static and dynamic halves.  That way it eliminates the
>    possibility of collisions if the configured subscriptions attempt to
>    set a subscription-id which might have already been dynamically
>    allocated.  A best practice is to use lower half the "identifier"
>    object's integer space when that "identifier" is assigned by an
>    external entity (such as with a configured subscription).  This
>    leaves the upper half of subscription identifiers available to be
>    dynamically assigned by the publisher.

Why would a server accept a dynamic subscription that clashes with
a configured subscription?

I don't think it would.
The issue is how applications share the range allocated for configured subscriptions.
... which is the reason why I was arguing for string based ids for configured subscriptions.

Humans seemingly find it easier to give unique names to things instead of unique numbers.  And if they want to use the string representation of numbers as unique names, well that also works.


+1

Given the incredibly long node names used in this YANG module, it's not as if any
attempt to reduce the payload size is being made, so it seems especially odd
that subscription-id size should be a factor.  The string representation of the
randomly generated 31 bit number is likely to be as long as a not-random string
selected by the application.

<Eric>  There are certainly good arguments for different approaches here.   To see a summary of the extensive WG analysis from last year here, check out:
https://github.com/netconf-wg/rfc5277bis/issues/6
Note: I don’t see in the thread request above to re-open this issue.  If that is not the case, please chime in.

Also on Andy’s point about long node names:
(a) From the beginning it has been assumed that in places where payload size is an issue, an efficient (non-text) encoding would be used.
(b) Almost all the event payload will be due to the contents of the encapsulated notifications.

Eric


Perhaps someone need to standardize the equivalent of DNS for subscription ids ;-)

Thanks,
Rob


Andy



/js

Andy

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>



_______________________________________________

Netconf mailing list

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

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