Subject: [Netconf] SN #6 String or Integer for Subscription ID (was RE: draft-ietf-netconf-subscribed-notifications, anything else from the two week look?)

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 19 Oct 2017 17:12:07 +0000

Trying to summarize for readability.  I have articulated a few more advantages to Integer, please feel free to let me know items I missed for String.

[A]  Integer
*********
(A1) Efficiency of notification message processing: Comparing two numbers is magnitudes faster than comparing two strings (representing the same numbers). Sorting and forwarding of incoming messages on the receiver so that they go to the right requesting application will be faster.

(A2) Size: A subscription id based on characters will be larger than transport based on integer. As we have IoT drafts relating to CBOR, we should look at efficiency.

(A3) Easier to automatically generate IDs for dynamic subscriptions.  Enables easier conventions for sequential issuance of subscription-ids which can then be interpreted by subscriber

(A4) Can augment (or add now in the base model) a leaf containing a string definition of a configured subscription.  This string would be passed as part of the "subscription-started" notification, so there would be no need to query the publisher for a meaning.  Greater verbosity and redundancy in text definitions would then both be allowed.  This text only need be passed once, and can be safely ignored by the receiver implementations.

(A5) Low power IoT receivers.    Many small receivers of the same subscription might consume the same feed with a minimally sized, easier to process header. (Henk can provide sources for the use cases here.)  

(A6) Subscription ID in the OpenConfig.yang model is also an integer (uint64)
See line 584 of: https://github.com/openconfig/public/blob/master/release/models/telemetry/openconfig-telemetry.yang 
Implementations supporting both model exposures will need to worry less about mapping.

[B] String
********
(B1) Easier to read and understand the sub-domain segmentation of the subscription-id space, as well as the creation of new sub-domains

(B2) If Kent's question on the possibility of encoding frequently sent text fields in CBOR as integer comes back as viable, then the Size advantages of [A] go away

[C] union of integer and string.  
*************************
As there are additional processing requirements in the receiver and key issues in the publisher, this would seem to have processing inefficiencies.  Does anyone want to argue for this?

Eric

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Oct 2017 19:26:37 +0200

> [C] union of integer and string.  

Are there?

type union {
  type uint64;
  type string;
}

In XML (or JSON), there is no processing at all, it all looks like a string anyway.
In CBOR, we could make the distinction.

(I wouldn’t mind A, but C sounds better to me than B.)

> (B2) If Kent's question on the possibility of encoding frequently sent text fields in CBOR as integer comes back as viable, then the Size advantages of [A] go away

I don’t understand how B2 is less complicated than C.

Grüße, Carsten

---

From: Robert Wilton <[email-masked]>
Date: Thu, 19 Oct 2017 19:22:42 +0100

I think that my preference is still [D]: Use strings as the key for 
configured subscriptions and then numerical ids for the operational 
subscriptions (and only put the numeric ids into the messages).

That is also how the OpenConfig telemetry module that you reference 
below works, i.e. strings for configured subscriptions and numerical ids 
for dynamic subscriptions:

  grouping telemetry-subscription-name-config {
     description
       "Configuration parameters relating to the configured
        name of the telemetry subscription. The name is a user
        configured string value which uniquely identifies the
        subscription in the configuration database.";

      leaf subscription-name {
        type string;
        description
          "User configured identifier of the telemetry
           subscription. This value is used primarily for
           subscriptions configured locally on the network
           element.";
      }
   }

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Oct 2017 11:32:25 -0700

On Thu, Oct 19, 2017 at 10:26 AM, Carsten Bormann <[email-masked]> wrote:

> > As there are additional processing requirements in the receiver and key
> issues in the publisher, this would seem to have processing
> inefficiencies.  Does anyone want to argue for this?
>
> Are there?
>
> type union {
>   type uint64;
>   type string;
> }
>
I do not have time to follow all the details of this verbose thread, but it
seems like
the human-friendly label is a presentation-layer issue, and should not be
sent on
the wire in every notification (regardless of encoding).

I would prefer "type uint32" for the subscription ID.
That provides 2 billion subscribed and 2 billion configured clients on 1
server.
IMO 1000 concurrent subscriptions per server sounds like a lot.
Typical values of "max-sessions" used by our customers -- 3 to 8.

> > (B2) If Kent's question on the possibility of encoding frequently sent
> text fields in CBOR as integer comes back as viable, then the Size
> advantages of [A] go away
>
Andy

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 19 Oct 2017 19:48:18 +0000

Hi Rob,

> Robert Wilton, October 19, 2017 2:23 PM
> 
> I think that my preference is still [D]: Use strings as the key for configured
> subscriptions and then numerical ids for the operational subscriptions (and
> only put the numeric ids into the messages).

In that case, you still have to coordinate the numerics across the independent domains, or have independent objects used at the receiver for sorting different and distributing the different types of subscriptions updates to the desired application.  
 
> That is also how the OpenConfig telemetry module that you reference below
> works, i.e. strings for configured subscriptions and numerical ids for dynamic
> subscriptions:

Ahh.  I looked there for subscription-id, not subscription-name.   I didn't realize they had explicitly the split subscription instances with different keys!  This would seem to add much a complexity for system management, reporting, troubleshooting, etc.  Plus as per above, telemetry applications might have a blend of configured and dynamic subscriptions.  This doubles key software constructs.

Eric

> > Trying to summarize for readability.  I have articulated a few more
> advantages to Integer, please feel free to let me know items I missed for String.
> >
> > [A]  Integer
> > *********
> > (A1) Efficiency of notification message processing: Comparing two numbers is
> magnitudes faster than comparing two strings (representing the same
> numbers). Sorting and forwarding of incoming messages on the receiver so
> that they go to the right requesting application will be faster.
> >
> > (A2) Size: A subscription id based on characters will be larger than transport
> based on integer. As we have IoT drafts relating to CBOR, we should look at
> efficiency.
> >
> > (A3) Easier to automatically generate IDs for dynamic subscriptions.
> > Enables easier conventions for sequential issuance of subscription-ids
> > which can then be interpreted by subscriber
> >
> > (A4) Can augment (or add now in the base model) a leaf containing a string
> definition of a configured subscription.  This string would be passed as part of
> the "subscription-started" notification, so there would be no need to query the
> publisher for a meaning.  Greater verbosity and redundancy in text definitions
> would then both be allowed.  This text only need be passed once, and can be
> safely ignored by the receiver implementations.
> >
> > (A5) Low power IoT receivers.    Many small receivers of the same
> subscription might consume the same feed with a minimally sized, easier to
> process header. (Henk can provide sources for the use cases here.)
> >
> > (A6) Subscription ID in the OpenConfig.yang model is also an integer
> > (uint64) See line 584 of:
> > https://github.com/openconfig/public/blob/master/release/models/teleme
> > try/openconfig-telemetry.yang Implementations supporting both model
> > exposures will need to worry less about mapping.
> >
> > [B] String
> > ********
> > (B1) Easier to read and understand the sub-domain segmentation of the
> > subscription-id space, as well as the creation of new sub-domains
> >
> issues in the publisher, this would seem to have processing inefficiencies.  Does
> anyone want to argue for this?
> >
> > Eric
> >

---

From: Robert Wilton <[email-masked]>
Date: Thu, 19 Oct 2017 21:15:28 +0100

Hi Erik,

> In that case, you still have to coordinate the numerics across the independent domains, or have independent objects used at the receiver for sorting different and distributing the different types o…
I'm not sure I get the distinction:

With a configured subscription I configure it with a name and look up a 
numerical subscription-id to manage the subscription with and demux 
notifications on.

With a configured subscription I create it with an RPC and get back a 
numerical subscription-id to manage the subscription with and demux 
notifications on.

Thanks,
Rob

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 19 Oct 2017 21:05:45 +0000

Hi Rob, 

I think you meant to say "dynamic subscription" for the second case in your email below?  

When creating a dynamic subscription, you invoke the <establish-subscription> RPC and get the subscription ID back as one of the output parameters.  It is the server that picks the identifier.  

A configured subscription is created using edit-config, not an RPC.  In that case, the client picks an identifier.  
--- Alex

> -----Original Message-----
> From: Robert Wilton [mailto:[email-masked]]
> Sent: Thursday, October 19, 2017 1:15 PM
> To: Eric Voit (evoit) <[email-masked]>; Martin Bjorklund <[email-masked]>;
> Juergen Schoenwaelder <[email-masked]>; Kent
> Watsen <[email-masked]>; Henk Birkholz
> <[email-masked]>; Alexander Clemm
> <[email-masked]>; Carsten Bormann <[email-masked]>
> Cc: [email-masked]
> Subject: Re: SN #6 String or Integer for Subscription ID (was RE: [Netconf]
> draft-ietf-netconf-subscribed-notifications, anything else from the two week
> look?)
> 
> Hi Erik,
> 
> 
> > In that case, you still have to coordinate the numerics across the
> independent domains, or have independent objects used at the receiver for
> sorting different and distributing the different types of subscriptions updates
> to the desired application.
> >> below works, i.e. strings for configured subscriptions and numerical
> >> ids for dynamic
> >> subscriptions:
> > Ahh.  I looked there for subscription-id, not subscription-name.   I didn't
> realize they had explicitly the split subscription instances with different keys!
> This would seem to add much a complexity for system management,
> reporting, troubleshooting, etc.  Plus as per above, telemetry applications
> might have a blend of configured and dynamic subscriptions.  This doubles
> key software constructs.
> >
> > Eric
> >
> >> numbers). Sorting and forwarding of incoming messages on the receiver
> >> so that they go to the right requesting application will be faster.
> >> based on integer. As we have IoT drafts relating to CBOR, we should
> >> look at efficiency.
> >>> Enables easier conventions for sequential issuance of
> >>> subscription-ids which can then be interpreted by subscriber
> >>>
> >> definition of a configured subscription.  This string would be passed
> >> as part of the "subscription-started" notification, so there would be
> >> no need to query the publisher for a meaning.  Greater verbosity and
> >> redundancy in text definitions would then both be allowed.  This text
> >> only need be passed once, and can be safely ignored by the receiver
> implementations.
> >> subscription might consume the same feed with a minimally sized,
> >> easier to process header. (Henk can provide sources for the use cases
> >> here.)
> https://github.com/openconfig/public/blob/master/release/models/tele
> >>> me try/openconfig-telemetry.yang Implementations supporting both
> >>> model exposures will need to worry less about mapping.
> >>>
> >>> [B] String
> >>> ********
> >>> (B1) Easier to read and understand the sub-domain segmentation of
> >>> the subscription-id space, as well as the creation of new
> >>> sub-domains
> >>>
> >>> (B2) If Kent's question on the possibility of encoding frequently
> >>> sent text fields in CBOR as integer comes back as viable, then the
> >>> Size advantages of [A] go away
> >>>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 19 Oct 2017 21:22:56 +0000

Hi Alex,
Hi Rob,

What Alex says is true.   But my original point was about the receiver's handling of inbound notification messages containing subscribed content.

If we have different object names for configured subscription and dynamic subscriptions (even if they both come across as integer), extra software structures are needed on the receiver to rectify this.  The result is that we are imposing complexity to the receiver unnecessarily.   This complexity can be eliminated with a unified address space under the control of the Publisher for both types of subscriptions.

Eric

> When creating a dynamic subscription, you invoke the <establish-subscription>
> RPC and get the subscription ID back as one of the output parameters.  It is the
> server that picks the identifier.
> 
> > To: Eric Voit (evoit) <[email-masked]>; Martin Bjorklund
> > <[email-masked]>; Juergen Schoenwaelder
> > <[email-masked]>; Kent Watsen
> > <[email-masked]>; Henk Birkholz
> > Subject: Re: SN #6 String or Integer for Subscription ID (was RE:
> > [Netconf] draft-ietf-netconf-subscribed-notifications, anything else
> > from the two week
> > look?)
> >
> > Hi Erik,
> >
> >
> > independent domains, or have independent objects used at the receiver
> > for sorting different and distributing the different types of
> > subscriptions updates to the desired application.
> > With a configured subscription I configure it with a name and look up
> > a numerical subscription-id to manage the subscription with and demux
> > notifications on.
> >
> > >> below works, i.e. strings for configured subscriptions and
> > >> numerical ids for dynamic
> > >> subscriptions:
> > reporting, troubleshooting, etc.  Plus as per above, telemetry
> > applications might have a blend of configured and dynamic
> > subscriptions.  This doubles key software constructs.
> > >
> > > Eric
> > >
> > >> advantages to Integer, please feel free to let me know items I
> > >> missed for
> > String.
> > >>> [A]  Integer
> > >>> *********
> > >> numbers). Sorting and forwarding of incoming messages on the
> > >> receiver so that they go to the right requesting application will be faster.
> > >> definition of a configured subscription.  This string would be
> > >> passed as part of the "subscription-started" notification, so there
> > >> would be no need to query the publisher for a meaning.  Greater
> > >> verbosity and redundancy in text definitions would then both be
> > >> allowed.  This text only need be passed once, and can be safely
> > >> ignored by the receiver
> > implementations.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 19 Oct 2017 23:08:12 +0100

Hi Alex,

> I think you meant to say "dynamic subscription" for the second case in your email below?
Yes.
> When creating a dynamic subscription, you invoke the <establish-subscription> RPC and get the subscription ID back as one of the output parameters.  It is the server that picks the identifier.
Yes.

> A configured subscription is created using edit-config, not an RPC.  In that case, the client picks an identifier.
No, that is not what I'm proposing.

The client chooses a unique name for the subscription, the server 
allocates a unique subscription id.  I.e. exactly the same block of 
software that is assigning a subscription id to a dynamic subscription.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 19 Oct 2017 23:28:02 +0100

Hi Eric,

On 19/10/2017 22:22, Eric Voit (evoit) wrote:
> If we have different object names for configured subscription and dynamic subscriptions (even if they both come across as integer), extra software structures are needed on the receiver to rectify this.
But I don't really agree on this point.  There will already be different 
client software to manage these given that configured subscriptions are 
managed through configuration and dynamic subscriptions are managed 
through RPCs.

But in terms of how the notifications are handled it can be identical 
for both cases (i.e. using the same code).  I.e demux from 
subscription-id to handling function.  In both dynamic and static 
configuration cases the client would need to learn what subscription-id 
has been allocated to the subscription by the publishing device.

>    The result is that we are imposing complexity to the receiver unnecessarily.
I would argue that we are removing complexity for the client by allowing 
them more freedom on how they name their subscriptions. The additional 
complexity is learning the mapping from "configured subscription name" 
to "system allocated subscription-id", but they require the same code 
for dynamic subscriptions anyway ...

>     This complexity can be eliminated with a unified address space under the control of the Publisher for both types of subscriptions.
In the solution that I propose there is a unified address space of 
numeric subscription-ids managed solely by the publisher.  But with the 
current scheme described in the drafts of using numerical ids for 
configured subscriptions then the ownership of the subscription-id 
address space is split between all clients and the single publisher, and 
it is this shared address space of numerical ids that I'm not that keen 
on, but like the efficiency of using numerical ids in the notification 
messages (and subsequent handling).

Or, comparing to the ACL YANG draft, do you think that it would be OK to 
use numerical ids to label each configured ACL rather than a string name?

Thanks,
Rob

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 20 Oct 2017 01:09:25 +0000

Re-summarizing based on discussions.  

[A]  Integer
*********
(A1)  + Efficiency of notification message processing: 

(A2)  + Message Size: 

(A3)  + Easier to automatically generate IDs for dynamic subscriptions

(A4)  + Addition of a leaf containing an optional string definition of a configured subscription.  This string would be passed as part of the "subscription-started" notification.

(A5)  + Low power IoT receivers.    Many small receivers of the same subscription might consume the same feed with a minimally sized, easier to process header. (Henk can provide sources for the use cases here.)  

(A6)  - Dividing the integer space in two (can consider Henk's option of moving from uint32 to int32, and requiring configured subscriptions to use negative numbers.)

[B] String
********
(B1)  + Easier to read and understand the sub-domain segmentation of the subscription-id space, as well as the creation of new sub-domains

(B2)  -  Loss of transport efficiencies in IoT as CBOR does not currently support the compression of frequently used strings to integer.

[C] string for config, integer for dynamic, integer on wire  
**********************************************
(C1) ++++ four of the advantages of [A]: (A1), (A2), (A3), (A5)

(C2) - use of different tables for different object names in receiver

(C3) - automated subscription correlation across different receivers a little more complex as the automatically assigned integer wouldn't be the same across publishers.   Could still derive it from "subscription-started" notification.

(C4) - some state change notifications become more complex as they must support different types of subscription ids within the notification (subscription-suspended, subscription-resumed, subscription-terminated, replay-completed.)

Eric

> From: Robert Wilton, October 19, 2017 6:28 PM
> 
> Hi Eric,
> 
> 
> > What Alex says is true.   But my original point was about the receiver's
> handling of inbound notification messages containing subscribed content.
> >
> > If we have different object names for configured subscription and dynamic
> subscriptions (even if they both come across as integer), extra software
> structures are needed on the receiver to rectify this.
> But I don't really agree on this point.  There will already be different client
> software to manage these given that configured subscriptions are managed
> through configuration and dynamic subscriptions are managed through RPCs.
> 
> But in terms of how the notifications are handled it can be identical for both
> cases (i.e. using the same code).  I.e demux from subscription-id to handling
> function.  In both dynamic and static configuration cases the client would need
> to learn what subscription-id has been allocated to the subscription by the
> publishing device.
> 
> I would argue that we are removing complexity for the client by allowing them
> more freedom on how they name their subscriptions. The additional
> to "system allocated subscription-id", but they require the same code for
> dynamic subscriptions anyway ...
> 
> 
> >     This complexity can be eliminated with a unified address space under the
> control of the Publisher for both types of subscriptions.
> In the solution that I propose there is a unified address space of numeric
> subscription-ids managed solely by the publisher.  But with the current scheme
> described in the drafts of using numerical ids for configured subscriptions then
> the ownership of the subscription-id address space is split between all clients
> and the single publisher, and it is this shared address space of numerical ids
> that I'm not that keen on, but like the efficiency of using numerical ids in the
> notification messages (and subsequent handling).
> 
> Or, comparing to the ACL YANG draft, do you think that it would be OK to use
> numerical ids to label each configured ACL rather than a string name?
> 
> Thanks,
> Rob
> 
<snip>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 20 Oct 2017 09:13:17 +0200 (CEST)

Hi,

I prefer Rob's proposal (C).  It aligns with other models for
configuration, and solves the dual value space issue.

/martin

---

From: "t.petch" <[email-masked]>
Date: Fri, 20 Oct 2017 11:53:26 +0100

----- Original Message -----
From: "Eric Voit (evoit)" <[email-masked]>
Sent: Friday, October 20, 2017 2:09 AM

A is efficient, B is verbose, C is complicated (sort of)..

I prefer A .

Tom Petch

> (A4)  + Addition of a leaf containing an optional string definition of
a configured subscription.  This string would be passed as part of the
"subscription-started" notification.
>
> (A5)  + Low power IoT receivers.    Many small receivers of the same
subscription might consume the same feed with a minimally sized, easier
to process header. (Henk can provide sources for the use cases here.)
>
> (A6)  - Dividing the integer space in two (can consider Henk's option
of moving from uint32 to int32, and requiring configured subscriptions
to use negative numbers.)
>
>
> [B] String
> ********
> (B1)  + Easier to read and understand the sub-domain segmentation of
the subscription-id space, as well as the creation of new sub-domains
>
> (B2)  -  Loss of transport efficiencies in IoT as CBOR does not
currently support the compression of frequently used strings to integer.
> (C3) - automated subscription correlation across different receivers a
little more complex as the automatically assigned integer wouldn't be
the same across publishers.   Could still derive it from
"subscription-started" notification.
>
> (C4) - some state change notifications become more complex as they
must support different types of subscription ids within the notification
(subscription-suspended, subscription-resumed, subscription-terminated,
replay-completed.)
> > In the solution that I propose there is a unified address space of
numeric

---

From: Robert Wilton <[email-masked]>
Date: Mon, 23 Oct 2017 16:16:11 +0100

Hi Tom,

What is your perceived complexity of C?  We are not talking of anything 
more complex than the equivalent of a cached DNS lookup, and the 
complexity seems to be identical to a dynamic subscriber.

My concern with using an integer id as a configured subscription id is 
that it looks like a premature optimization.  In fact, it feels somewhat 
similar to combined config + state problem that we currently trying to 
unravel with the NMDA architecture ;-)

Subscription configuration, dynamic subscription requests, and actual 
operational subscriptions all have different data lifecycles, hence 
temporally they should exist in different tables anyway.

An implementation can choose to "optimize" these 3 tables into a single 
data structure if they want, this isn't hard to code.  In the same way a 
implementation can store configuration and operational state in the same 
tree structure if they wish (although I suspect that the accidental 
complexity that gets introduced may outweigh the perceived benefits of 
combining them).

Conflating a identifier to uniquely describe a configuration object, and 
a system allocated identifier for an operational subscription object 
seems ill advised to me.

It is also worth noting that the current draft doesn't actually enforce 
how the configuration and operational subscription-id space is split (it 
uses a SHOULD not a MUST).  So, even if a client chooses subscription id 
"X" for a particular type of subscription, then it needs to cope with 
the fact that the subscription id may already be in use for some devices 
and hence it needs to try again to find another id that is not in use.  
I bet the code to handle this is far more complex than the code required 
to handle a dynamic id allocated to a statically configured subscription.

Besides if they really don't want to handle the mapping from 
subscription name to operational subscription-id then they could 
allocate a different port number for each configured subscription, and 
avoid the need for any dynamic mapping.

Thanks,
Rob

On 20/10/2017 11:53, t.petch wrote:
> .

---

From: "t.petch" <[email-masked]>
Date: Mon, 23 Oct 2017 17:43:03 +0100

---- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Monday, October 23, 2017 4:16 PM

Rob

When you said

"If there any possibility that the notification format might impact the
subscriber or YANG push configuration? E.g. the encoding of the
subscription identifier could affect what the associated configuration
model looks like.

If so, then it feels like spending a couple months with the WG trying to
nail down the notification format would be a good idea. Then the
subscription and YANG push drafts could formally depend on the new
notification format. "

I thought yes that to me is logical and so (may be) simple.

However, with things as they are, then the current definition is string
and so there is a sound argument for staying with that (even if it seems
to me to reflect the world view before YANG came along, when strings
made up a larger part of our life).  In future, or starting afresh, I
see an integer as a better identifier

Having more than one way of doing things,
"string for config, integer for dynamic, integer on wire"
well, I find having more than one way as more complex than having one
way.

I do not see an analogy with config+state and NMDA, rather I see one
namespace which only needs one data type of identifier, whatever that
may be.

Tom Petch

> > subscription might consume the same feed with a minimally sized,
easier
sub-domains
> >>> through configuration and dynamic subscriptions are managed
through
> > RPCs.
> >>> cases (i.e. using the same code). I.e demux from subscription-id
to
> > handling
> >>> function. In both dynamic and static configuration cases the
client
> > would need
> >>> to learn what subscription-id has been allocated to the
subscription
> > by the
> >>>>      This complexity can be eliminated with a unified address
space
> > under the
> >>> the ownership of the subscription-id address space is split
between
> > all clients

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 23 Oct 2017 17:18:29 +0000

> From: t.petch, October 23, 2017 12:43 PM
> 
> subscriber or YANG push configuration? E.g. the encoding of the subscription
> identifier could affect what the associated configuration model looks like.
> 
> If so, then it feels like spending a couple months with the WG trying to nail
> down the notification format would be a good idea. Then the subscription and
> YANG push drafts could formally depend on the new notification format. "
> 
> However, with things as they are, then the current definition is string and so
> there is a sound argument for staying with that (even if it seems to me to
> reflect the world view before YANG came along, when strings made up a larger
> part of our life).  In future, or starting afresh, I see an integer as a better
> identifier

Just one clarification above.  The current definition is integer.  This model moved to integer at the beginning of 2016.

> Having more than one way of doing things, "string for config, integer for
> dynamic, integer on wire"
> well, I find having more than one way as more complex than having one way.

Agree.

As an example of the complexities, the subtrees maintaining receiver operational statistics would need to be duplicated, or given an alternate key.

Eric

> namespace which only needs one data type of identifier, whatever that may
> be.
> 
> Tom Petch
> 
> > Thanks,
> > Rob
> >
> >

---

From: Robert Wilton <[email-masked]>
Date: Mon, 23 Oct 2017 18:31:40 +0100

> As an example of the complexities, the subtrees maintaining receiver operational statistics would need to be duplicated, or given an alternate key.
No.  It can be a single table key'ed by subscriber-id.

Every subscription (configured or dynamic) is handled the same way and 
is allocated (by the system) a unique subscriber-id when the operational 
subscription is created.

The "subscription name" doesn't identify an operational subscription, it 
is just a friendly (for the operator) name to identify a block of 
configuration that is then used to create a subscription.

Thanks,
Rob

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 23 Oct 2017 18:04:45 +0000

> From: Robert Wilton -X, October 23, 2017 1:32 PM
> 
> >>> What is your perceived complexity of C? We are not talking of
> >>> anything more complex than the equivalent of a cached DNS lookup,
> >>> and the complexity seems to be identical to a dynamic subscriber.
> >>>
> >>> My concern with using an integer id as a configured subscription id
> >>> is that it looks like a premature optimization. In fact, it feels
> >> somewhat
> >>> similar to combined config + state problem that we currently trying
> >>> to unravel with the NMDA architecture ;-)
> >>>
> >>> Subscription configuration, dynamic subscription requests, and
> >>> actual operational subscriptions all have different data lifecycles,
> >>> hence temporally they should exist in different tables anyway.
> >>>
> >>> data structure if they want, this isn't hard to code. In the same
> >>> way
> >> a
> >>> complexity that gets introduced may outweigh the perceived benefits
> >>> of combining them).
> >>>
> >>> "X" for a particular type of subscription, then it needs to cope
> >>> with the fact that the subscription id may already be in use for
> >>> some
> >> devices
> >>> allocate a different port number for each configured subscription,
> >>> and avoid the need for any dynamic mapping.
> >>
> >> Rob
> >>
> >> When you said
> >>
> >> "If there any possibility that the notification format might impact
> >> the subscriber or YANG push configuration? E.g. the encoding of the
> >> subscription identifier could affect what the associated configuration model
> looks like.
> >>
> >> If so, then it feels like spending a couple months with the WG trying
> >> to nail down the notification format would be a good idea. Then the
> >> However, with things as they are, then the current definition is
> >> string and so there is a sound argument for staying with that (even
> >> if it seems to me to reflect the world view before YANG came along,
> >> when strings made up a larger part of our life).  In future, or
> >> starting afresh, I see an integer as a better identifier
> > Just one clarification above.  The current definition is integer.  This model
> moved to integer at the beginning of 2016.
> >
> >> Having more than one way of doing things, "string for config, integer
> >> for dynamic, integer on wire"
> > As an example of the complexities, the subtrees maintaining receiver
> operational statistics would need to be duplicated, or given an alternate key.

It would have been clearer if I had said 'alternative key'.  In your proposal the key used for config operations is different than the key for retrieving operational statistics.  So finding your operational data takes an extra step.  Yes this is doable, but there more to do.

As a side note: if someone deletes a configured-subscription, there needs to be extra stuff in the implementation to ensure any leafrefs in the operational subscription table pointing to the deleted configured subscription are also cleaned up.  

Eric

> Every subscription (configured or dynamic) is handled the same way and is
> allocated (by the system) a unique subscriber-id when the operational
> subscription is created.
> 
> The "subscription name" doesn't identify an operational subscription, it is just
> a friendly (for the operator) name to identify a block of configuration that is
> then used to create a subscription.

Which 

With a friendly name, why not just have that be a non-key (and maybe unique) object?

> >>>>> (A4)  + Addition of a leaf containing an optional string
> >>>>> definition
> >> of
> >>>>>>> If we have different object names for configured subscription
> >>>>>>> and
> >>>> dynamic
> >>>>>>>      The result is that we are imposing complexity to the
> >>>>>>> receiver
> >>>> unnecessarily.
> >>>>>> Or, comparing to the ACL YANG draft, do you think that it would
> >>>>>> be
> >>>> OK to use

---

From: Robert Wilton <[email-masked]>
Date: Tue, 24 Oct 2017 14:16:42 +0100

On 23/10/2017 19:04, Eric Voit (evoit) wrote:
> It would have been clearer if I had said 'alternative key'.  In your proposal the key used for config operations is different than the key for retrieving operational statistics.
Yes.

>    So finding your operational data takes an extra step.  Yes this is doable, but there more to do.
Not necessarily.  You can still perform this as a single get/get-data 
request using an XPath query expression (if supported).

> As a side note: if someone deletes a configured-subscription, there needs to be extra stuff in the implementation to ensure any leafrefs in the operational subscription table pointing to the delete…
I'm not sure that this is really a problem.  If you delete a configured 
subscription then I would expect an implementation to also delete the 
state associated with an operational subscription entry.

> With a friendly name, why not just have that be a non-key (and maybe unique) object?
Only because I perceive that it is easier, more flexible, and likely 
more descriptive, for a client to generate unique string names for a 
configured list item than a unique numeric index.

Regarding adding a friendly name as a non-key:  This might help, but 
equally, it might not be that useful in practice.  Once you require 
unique numeric keys for configuration then I think that you already 
force the operator to create a bijective mapping from a meaningful 
subscription name to a unique numeric subscription-id anyway, so they 
can always do the conversion if required.

Thanks,
Rob

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 25 Oct 2017 00:29:15 +0000

Just one brief comment regarding the "friendly name that is a non-key":  I am not sure I understand this argument.  Subscriptions are used by client applications; I don't see many operators typing these.  If an application wants to use user-friendly names, allow to attach tags to organize subscriptions in a UI, etc, by all means it can do that, but let it be added by the application, no need to reflect that in the underlying name.  Personally, I find the simpler integer-based scheme with a single integer - well, simpler.  

--- Alex

> Sent: Tuesday, October 24, 2017 6:17 AM
> To: Eric Voit (evoit) <[email-masked]>; t.petch <[email-masked]>;
> Alexander Clemm <[email-masked]>; Martin Bjorklund
> <[email-masked]>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> university.de>; Kent Watsen <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Netconf] SN #6 String or Integer for Subscription ID (was RE:
> > It would have been clearer if I had said 'alternative key'.  In your proposal
> the key used for config operations is different than the key for retrieving
> operational statistics.
> Yes.
> 
> Not necessarily.  You can still perform this as a single get/get-data request
> using an XPath query expression (if supported).
> 
> >
> > As a side note: if someone deletes a configured-subscription, there needs
> to be extra stuff in the implementation to ensure any leafrefs in the
> operational subscription table pointing to the deleted configured
> subscription are also cleaned up.
> subscription then I would expect an implementation to also delete the state
> associated with an operational subscription entry.
> 
> 
> >
> >
> > Eric
> >
> >> Every subscription (configured or dynamic) is handled the same way
> >> and is allocated (by the system) a unique subscriber-id when the
> >> operational subscription is created.
> >>
> >> The "subscription name" doesn't identify an operational subscription,
> >> it is just a friendly (for the operator) name to identify a block of
> Only because I perceive that it is easier, more flexible, and likely more
> descriptive, for a client to generate unique string names for a configured list
> item than a unique numeric index.
> 
> Regarding adding a friendly name as a non-key:  This might help, but equally,
> it might not be that useful in practice.  Once you require unique numeric keys
> for configuration then I think that you already force the operator to create a
> bijective mapping from a meaningful subscription name to a unique numeric
> subscription-id anyway, so they can always do the conversion if required.
> 
> Thanks,
> Rob

---

From: "t.petch" <[email-masked]>
Date: Wed, 25 Oct 2017 12:14:59 +0100

----- Original Message -----
From: "Eric Voit (evoit)" <[email-masked]>
Sent: Monday, October 23, 2017 6:18 PM

<snip>

> > However, with things as they are, then the current definition is
string and so
> Just one clarification above.  The current definition is integer.
This model moved to integer at the beginning of 2016.

Eric

Sloppy wording on my part - I was harking back to RFC5277 when I said
that the current definition is string.

That RFC is the one we are (or are not:-) updating or replacing so I see
it as the current definition.

Tom Petch

> As an example of the complexities, the subtrees maintaining receiver
operational statistics would need to be duplicated, or given an
alternate key.