Subject: [Netconf] draft-ietf-netconf-subscribed-notifications, anything else from the two week look?

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

Thanks everyone who has commented on draft-ietf-netconf-subscribed-notifications so far during the two week focused review.   I believe the changes discussed on and agreed to on this list so far are embedded in a preliminary version of v06 which is located at:
https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-06.txt
(Many thanks to Martin.  I do need to triple check to see that I got all of the agreements with Martin covered, but I think I did.)

This leaves the following, please let me know if I have missed anything or if you have something new:

(1) Source VRF or leafref to ietf-network-instance
https://github.com/netconf-wg/rfc5277bis/issues/5
Summary: to identify the source VRF, do we do (i) a leafref to the ietf-network-instance model, or (ii) use the string data type for route distinguisher and route target as defined in draft-ietf-rtgwg-routing-types.
Recommendation (ii) as this will be far closer to what implementers will be doing for the foreseeable future.  But I could live with (i) even though I am not sure anyone is implementing it (which results in unnecessary vendor augmentations), and it creates an unnecessary dependency on schema mount.

(2) Configured Subscriptions - Protocol, Encoding
https://github.com/netconf-wg/rfc5277bis/issues/4
Summary: Should the transport protocol and the encoding should be the same for all configured receivers of a single subscription?
Recommendation: encoding should stay the same for all receivers, but transport should be allow to vary be receiver.  Reasoning:  encoding is a publisher function, and unlikely to vary.  Transport is dependent somewhat on the receiver capabilities, and allowing variation here enables seamless incremental conversion of receivers and the ability to have the same configured subscription-id available to correlate across receivers using different transports.

(3) Properly documenting the eventual move from 5277 one way notifications to subscribed-messages
https://github.com/netconf-wg/rfc5277bis/issues/3
Summary: I think that this issue is not a barrier to WGLC as the current draft removes any normative reference to the new notification-messages draft, and acknowledges that we should update this document when notification-messages completes.

(4) Martin is also asking that a subscription identifier to be a string rather than an integer.   While this is technically open between Martin & I, I believe the case is very strong for integer  -- so much so that my belief is that  this need not be turned into a formal issue.  Look for others' opinions on the alias and chime in.  If anyone else strongly feels "string" is the right way to go, we can certainly create an issue to track.

Beyond that:

- There are other minor comments which are hopefully in their last stages with Martin
- There are comments of Martin's on this document which will drive some revised content into draft-ietf-netconf-netconf-event-notifications. (Head's up Alberto ;-)
- I plan on integrating Tim's suggestion that we have a separate receivers container for configured subscriptions.  As I am not hearing any issues from people (other than a little more complexity) I will add that in tomorrow.

Robert also has an umbrella question on the draft set dependency to notification-messages. (I.e., Not specific to this draft.)  As we have multiple known implementations of YANG push over NETCONF, it will be quite a while before notification-messages solidifies, and we need to chunk this rather large set of work, I am hoping this too resolves quickly.

Thanks,
Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Oct 2017 09:28:33 +0200 (CEST)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> (4) Martin is also asking that a subscription identifier to be a
> string rather than an integer.  While this is technically open between
> Martin & I, I believe the case is very strong for integer -- so much
> so that my belief is that this need not be turned into a formal issue.
> Look for others' opinions on the alias and chime in.  If anyone else
> strongly feels "string" is the right way to go, we can certainly
> create an issue to track.

My point is that for configured list items that don't have a "natural"
key (ip addres or whatever), in YANG we normally use a key "name" of
type "string".  The idea is that strings are easier to work with and
more flexible as identifiers in the configuration.  It is easier to
work with a subscription called "critical-to-noc", than "37".

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Oct 2017 09:39:51 +0200

> work with a subscription called "critical-to-noc", than "37".

I agree with Martin and note that you can use the string "37" or "a"
as well if you need short and difficult to memorize identifiers.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

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

> work with a subscription called "critical-to-noc", than "37".
If the subscription id is configured by a client, then generally a 
string seems like a more friendly choice.  E.g. as a point of comparison 
I note that the ACL YANG model is using names to identify ACLs rather 
than numerical ids ...

If the subscription id is being generated by a computer (e.g. the 
device) then a numerical id is better, since it is easy to generate the 
next new one.

For encoding purposes, with XML or JSON, whether it is a string or a 
number doesn't seem to make any real difference.  But if the 
subscription uses a binary encoding (e.g. CBOR) then a numerical field 
is likely to be more compact.

If the same subscription id is used for both the configured list and 
operational list then I think that I would prefer a string, where part 
of the value space is reserved for device assigned ids, e.g. "all device 
subscriptions use a string format like "svr-<number>".

But I actually wonder whether the solution here shouldn't be to have 
different indexes for the configured vs operational list of subscriptions:

E.g.
- the subscription configuration uses an arbitrary string name, but gets 
allocated an internal numerical subscription id (which is available in 
<operational>).
- the internal subscriptions are indexed by a system assigned numerical id.
- notifications always include the system assigned numeric id (for 
compactness).
  - notifications could also include the configured name.  This could be 
controlled via a config leaf in a configured subscription.  Or when 
establishing a subscription via RPC it might be useful if the client 
could also provide a string name/description of the subscription (which 
again could be included/not included in the notifications via a boolean 
input parameter).

Thanks,
Rob

> .

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Oct 2017 13:11:31 +0200

Sure, why not make things complex to save a few bytes occasionally.

/js

On Thu, Oct 19, 2017 at 10:48:15AM +0100, Robert Wilton wrote:
> If the subscription id is configured by a client, then generally a string
> seems like a more friendly choice.  E.g. as a point of comparison I note
> that the ACL YANG model is using names to identify ACLs rather than
> numerical ids ...
> 
> If the subscription id is being generated by a computer (e.g. the device)
> then a numerical id is better, since it is easy to generate the next new
> one.
> 
> For encoding purposes, with XML or JSON, whether it is a string or a number
> doesn't seem to make any real difference.  But if the subscription uses a
> binary encoding (e.g. CBOR) then a numerical field is likely to be more
> compact.
> 
> operational list then I think that I would prefer a string, where part of
> the value space is reserved for device assigned ids, e.g. "all device
> establishing a subscription via RPC it might be useful if the client could
> also provide a string name/description of the subscription (which again
> could be included/not included in the notifications via a boolean input
> parameter).
> 
> Thanks,
> Rob
> 
> 
> > 
> > 
> > /martin
> > 
> > 
> > 
> > .
> > 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

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

Hi Robert,

> From: Robert Wilton, Thursday, October 19, 2017 5:48 AM
> 
> >> string rather than an integer.  While this is technically open
> >> between Martin & I, I believe the case is very strong for integer --
> >> so much so that my belief is that this need not be turned into a formal
> issue.
> If the subscription id is configured by a client, then generally a string seems like
> a more friendly choice.  E.g. as a point of comparison I note that the ACL YANG
> model is using names to identify ACLs rather than numerical ids ...
> 
> device) then a numerical id is better, since it is easy to generate the next new
> one.

Yes.  This is the case for dynamic subscriptions, which are likely to be dominant.

> doesn't seem to make any real difference.  But if the subscription uses a binary
> encoding (e.g. CBOR) then a numerical field is likely to be more compact.

A draft with CBOR and YANG Push was submitted to 
https://www.ietf.org/internet-drafts/draft-birkholz-yang-push-coap-problemstatement-00.txt 
so we have a known use for the more compact encoding

> If the same subscription id is used for both the configured list and operational
> list then I think that I would prefer a string, where part of the value space is
> reserved for device assigned ids, e.g. "all device subscriptions use a string
> format like "svr-<number>".

This could work, but:
a) there is less efficiency of transport
b) there is extra cost for the receiver in forwarding the right notification messages to the right context.  (a small cost, but potentially a frequent one)
c) there is still internal segmentation of the address space.   
Current proposal is compact and easy to understand without reserved elements of a string.

> But I actually wonder whether the solution here shouldn't be to have different
> indexes for the configured vs operational list of subscriptions:
>
> E.g.
> controlled via a config leaf in a configured subscription.  Or when establishing a
> subscription via RPC it might be useful if the client could also provide a string
> name/description of the subscription (which again could be included/not
> included in the notifications via a boolean input parameter).

There are good elements here, but there are several reasons why this isn't optimal:
a) the boolean means more complexity, including the need for multiple identifiers sent to the receiver
b) without the boolean, an operator would not be able to choose well known subscription numbers for specific services across publishers (which is very useful for decoupled operations where the receiver might gain the meaning of the incoming content completely from a pre-established understanding of the subscription id.)
c) without the boolean, requires the return of the system assigned numerical identifier to the configuration system for troubleshooting.
d) with the boolean, the receiver would have different behaviors for dynamic and configured subscriptions
e) the extra level of indirection is likely to have other unexpected impacts on ease of operation / troubleshooting.

Thanks,
Eric

---

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

> Sure, why not make things complex to save a few bytes occasionally.
I'm not particularly familiar with IOT devices, but my understanding is 
that it is desirable to minimize bandwidth (and frequency of messages) 
as much as possible to reduce power usage.

Similarly, for high end routers, customers have a desire to get as much 
telemetry information off the device as possible with minimum of 
latency.  E.g. send us everything you have and we will figure it with 
the information is important or can just be discarded.  And by 
everything, I think that ideally they would like to see every change to 
any data node in the operational datastore ...

I don't know if YANG Push is intended to be IETF's solution to telemetry 
- I think that it could/should be, but I think that the efficiency of 
encoding the notifications is important for it to compete with say gNMI 
(draft-openconfig-rtgwg-gnmi-spec-00), so the additional complexity may 
be worth it ...

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Oct 2017 14:05:12 +0200

If you can prove that it actually makes a difference at the system
level.

/js

On Thu, Oct 19, 2017 at 01:01:19PM +0100, Robert Wilton wrote:
> I'm not particularly familiar with IOT devices, but my understanding is that
> it is desirable to minimize bandwidth (and frequency of messages) as much as
> possible to reduce power usage.
> 
> telemetry information off the device as possible with minimum of latency. 
> E.g. send us everything you have and we will figure it with the information
> is important or can just be discarded.  And by everything, I think that
> ideally they would like to see every change to any data node in the
> operational datastore ...
> 
> I don't know if YANG Push is intended to be IETF's solution to telemetry - I
> think that it could/should be, but I think that the efficiency of encoding
> the notifications is important for it to compete with say gNMI
> (draft-openconfig-rtgwg-gnmi-spec-00), so the additional complexity may be
> worth it ...
> 
> Thanks,
> Rob
> 
> 
> > 
> > /js
> >

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Oct 2017 14:06:50 +0200

For me this is a very interesting discussion, because we will have many instances of this type of issue in the future.

Netconf and YANG are fundamentally XML technologies, and the XML roots shine through at every bend.  There is some optimism that YANG can be used at a level of resource availability (“constrained nodes”) where XML would have been a problem.  There are some issues that basing the YANG semantics based on the XML serialization cause for type choices; we think we have them mostly under control for yang-cbor.

Now how do we get the simpler type (unsigned int) for internal elements of the protocol mechanics?  I’m not sure this cannot simply be solved by a type choice between text string and uint; an XML based implementation will be none the wiser and a CBOR implementation can do the right thing.

This keeps the complexity confined to where the actual benefit is, which would generally make this designer happy.

Grüße, Carsten

> On Oct 19, 2017, at 13:11, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

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

Hi Rob,

> Robert Wilton, October 19, 2017 8:01 AM
<snip>
> - I think that it could/should be, 

YANG-Push always had this goal.  See RFC-7923.

> but I think that the efficiency of encoding the
> notifications is important for it to compete with say gNMI (draft-openconfig-
> rtgwg-gnmi-spec-00), so the additional complexity may be worth it ...

YANG-push predates both GMNI and OC-Telemetry.yang.  

We have always had transport independence and binary encodings for efficiency as an objective.  For example, see slide 13 of:
https://github.com/netconf-wg/yang-push/blob/master/Subscriptions-Intro-IETF96.ppt 
 
There need be no extra complexity added to the notification message headers accomplish what is needed.

Eric

---

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

Hi Martin,

> From: Martin Bjorklund, October 19, 2017 3:29 AM
>
> Hi,
> 
> key (ip addres or whatever), in YANG we normally use a key "name" of type
> "string".  The idea is that strings are easier to work with and more flexible as
> identifiers in the configuration.  It is easier to work with a subscription called
> "critical-to-noc", than "37".

As the discussion in growing wider with IoT.   I have added it as:
https://github.com/netconf-wg/rfc5277bis/issues/6 

I maintain that it is far more important to optimize for speed and size of notification messages.  (See Carsten's email.)   Plus there is no reason that people cannot augment the model with a more human readable string if one is desired for configured subscriptions.

Eric

---

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

Hi Juergen,

> From: Juergen Schoenwaelder, October 19, 2017 3:40 AM
> 

What do you think of adding a string leaf which is a description for a configured description?

That would allow an even more robust documentation of the configured subscriptions purpose, but still allow for maximum efficiency in transport.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Oct 2017 15:27:45 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > type
> I maintain that it is far more important to optimize for speed and
> size of notification messages.  (See Carsten's email.)  Plus there is
> no reason that people cannot augment the model with a more human
> readable string if one is desired for configured subscriptions.

You cannot change the key via augmentation, so even if you augment a
leaf of type string, the client still have to provide the integer.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Oct 2017 15:29:30 +0200 (CEST)

> If you can prove that it actually makes a difference at the system

Right.  And the "performance hit" would be at the *receiver*, which
probably is not a constrained device.

/martin

---

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

> > > > between Martin & I, I believe the case is very strong for integer
> > > > -- so much so that my belief is that this need not be turned into a formal
> issue.
> > > > Look for others' opinions on the alias and chime in.  If anyone
> > > > else strongly feels "string" is the right way to go, we can
> > > > certainly create an issue to track.
> > >
> You cannot change the key via augmentation, so even if you augment a leaf of
> type string, the client still have to provide the integer.

Exactly.   I believe the string leaf would provide the option of text description to describe the configured subscription without impacting transport efficiency.   As this leaf would be included a "subscription-started" notification, it can be included as the context provided to the receiver without impacting the efficiency of normal subscribed content delivery.

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Oct 2017 15:46:18 +0200

> possible to reduce power usage.

If the target are constrained IoT devices, how many subscription to
you expect them to handle? If you name subscriptions with a single
ASCII letter or digit, you get 26+26+10 = 62 notification you can
distinguish with a single byte string. Add a few more punctuation
characters and you get closer to 80 subscriptions.

The question is whether every client will have to deal with numeric
identifiers and possibly mappings between identifier spaces just to
please some devices that are seriously resource constrained but need
to handle more than say 80-100 subscriptions. At least there is a
certain chance that these devices we optimize for will never exist in
the real world.

/js

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 19 Oct 2017 15:47:03 +0200

>> as well if you need short and difficult to memorize identifiers.

I am a little bit puzzled by this conversation. If I understand it 
correctly, a small identifier, such as 37 is considered more difficult 
to remember as the term "critical-to-noc". In respect human long term 
memory, I would assume (I do not know) that is true.

More important though, I think, than the difficulty to memorize an 
identifier (which remains arguable) is the fact that critical-to-noc" is 
self-descriptive in respect to humans and 37 is not.

In respect to computing contexts and efficient processing, I would dare 
to say that is not correct. 37 can be very well self-descriptive and my 
computer can remember stuff way better than I can.

 From my POV, "critical-to-noc" seems to be a human readable description 
for the effective identifier that is 37. What do others think about my 
point of view?

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 19 Oct 2017 15:53:55 +0200

Hello Jürgen,

In certain scopes a byte string with the size of 1 is an excellent 
identifier, I think. Even a text string with the size of 1 would be okay 
(assuming 62-80) in a lot of usage scenarios.

If that would be okay, how is a number (e.g. a unit64, if you require an 
example for a specific type) so different from that?

Viele Grüße,

Henk

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Oct 2017 15:54:52 +0200

> That would allow an even more robust documentation of the configured subscriptions purpose, but still allow for maximum efficiency in transport.

So we make the key numeric, then we add an additional leaf, then we
need to do a search to find an entry by the additional leaf value. See
my other message: we may be putting extra burden on all clients to
please devices that may never really exist. Does not sound like a good
engineering tradeoff to me. So how many subscriptions do we expect
constrained devices to handle?

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 19 Oct 2017 14:56:25 +0100

Hi Carsten,

I just want to check that I correctly understand your suggestion: I 
think that you are suggesting that the a subscription-id could be 
defined as a YANG union type of a string and an integer.  Is that right?

If so, then that might work, and has the additional benefit that the 
configured subscriptions and operational subscriptions could be 
represented as a single NMDA tree in YANG rather than two separate trees 
in the current draft.

Thanks,
Rob

---

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

> From: Henk Birkholz, October 19, 2017 9:47 AM
>
> I am a little bit puzzled by this conversation. If I understand it correctly, a small
> identifier, such as 37 is considered more difficult to remember as the term
> "critical-to-noc". In respect human long term memory, I would assume (I do
> not know) that is true.
> 
> More important though, I think, than the difficulty to memorize an identifier
> (which remains arguable) is the fact that critical-to-noc" is self-descriptive in
> respect to humans and 37 is not.
> 
> In respect to computing contexts and efficient processing, I would dare to say
> that is not correct. 37 can be very well self-descriptive and my computer can
> remember stuff way better than I can.
> 
>  From my POV, "critical-to-noc" seems to be a human readable description for
> the effective identifier that is 37. What do others think about my point of
> view?

+1.

Human readable can be accomplished via an optional description leaf which would only be passed as part of the "notification-started".   And human readable + efficient for transport is more likely to result in string collision anyway.  Think about how hard it is to come up with unique object names even within the confines of a single namespace.

Eric

> > That would allow an even more robust documentation of the configured
> subscriptions purpose, but still allow for maximum efficiency in transport.
> >
> > Eric
> >
> >> /js
> >>
> >> --

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Oct 2017 16:02:03 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> represented as a single NMDA tree in YANG rather than two separate
> trees in the current draft.

I don't think so - what prevents a client for configuring an entry
with an integer?

*if* we really need to use an integer in the payload, I think your
solution could work, but without your last step - i.e:

  - the subscription configuration uses an arbitrary string name, but gets
    allocated an internal numerical subscription id (which is available in
    <operational>).
  - the internal subscriptions are indexed by a system assigned numerical
    id.
  - notifications always include the system assigned numeric id (for
    compactness).

But I'm not convinced this "optimization" is worth the additional
complexity.

/martin

> > For me this is a very interesting discussion, because we will have
> > many instances of this type of issue in the future.
> >
> > Netconf and YANG are fundamentally XML technologies, and the XML roots
> > shine through at every bend.  There is some optimism that YANG can be
> > used at a level of resource availability (“constrained nodes”) where
> > XML would have been a problem.  There are some issues that basing the
> > YANG semantics based on the XML serialization cause for type choices;
> > we think we have them mostly under control for yang-cbor.
> >
> > Now how do we get the simpler type (unsigned int) for internal
> > elements of the protocol mechanics?  I’m not sure this cannot simply
> > be solved by a type choice between text string and uint; an XML based
> > implementation will be none the wiser and a CBOR implementation can do
> > the right thing.
> >
> > This keeps the complexity confined to where the actual benefit is,
> > which would generally make this designer happy.
> >
> > Grüße, Carsten
> >
> >
> >> On Oct 19, 2017, at 13:11, Juergen Schoenwaelder
> >> <[email-masked]> wrote:
> >>
> >>> string
> >>> device)
> >>> number
> >>> of
> >>> - the internal subscriptions are indexed by a system assigned numerical
> >>> - id.
> >>> could

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Oct 2017 16:07:59 +0200

Henk,

the point is that a string can be long or short and with strings it is
not hard-wired in the data model how key values have to be chosen.
The key values can be short or long, they may be meaningful to users /
programmers or not, they may carry additional semantics that are
meaningful to applications or they may not. If I prefer to name things
with single byte strings, I can do so as long as I do not need more
than ~80 of them.

/js

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 19 Oct 2017 16:08:51 +0200

Hello Jürgen,

in the scenario you illustrate, why would you want to do a search by the 
"additional leaf" and create that "extra burden on all clients"? Why not 
just use the numeric key? This still leaves me puzzled. It would be like 
google'ing me via my description rather than my name?

Yes, I agree, that would be burdensome, but why would you do that in the 
first place?

Maybe I am missing something vital here.

Viele Grüße,

Henk

---

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

> I don't think so - what prevents a client for configuring an entry
Nothing.  A client can use an integer if they want.  But the numerical 
subscriber-id space would need to be partitioned between client 
configured values and internally allocated ids (as is required with the 
current numerical scheme).

At the moment the draft suggests that the low half of the 32 bit number 
range be assigned to client subscriber ids, and the rest to internal 
subscriber ids.  If we were to use a union of string and numerical 
value, then I would suggest that the numerical partitioning is the other 
way round to get the better binary encoding efficiency of low subscriber 
ids for the more common dynamic subscriptions.

> But I'm not convinced this "optimization" is worth the additional
I think that the notification messages have to be as small/concise as is 
reasonably possible.  I think that one of the the limiting factors on 
how much telemetry data can be generated off any device is the point 
that you saturate the bandwidth of the management port.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Oct 2017 16:26:36 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> configured values and internally allocated ids (as is required with
> the current numerical scheme).

But if we rely on a partitioning based on a convention, we could as well
have a union and use the convention that clients always use strings.

But I don't think that we should rely on a convention...

/martin

> At the moment the draft suggests that the low half of the 32 bit
> number range be assigned to client subscriber ids, and the rest to
> internal subscriber ids.  If we were to use a union of string and
> numerical value, then I would suggest that the numerical partitioning
> is the other way round to get the better binary encoding efficiency of
> low subscriber ids for the more common dynamic subscriptions.
> 
> >
> I think that the notification messages have to be as small/concise as
> is reasonably possible.  I think that one of the the limiting factors
> on how much telemetry data can be generated off any device is the
> point that you saturate the bandwidth of the management port.
> 
> Thanks,
> Rob
> 
> 
> >
> >
> >
> > /martin
> >
> >
> >
> >
> >> Thanks,
> >> Rob
> >>
> >>
> >>>>>    - notifications could also include the configured name.  This could
> >>>>>    - be

---

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

Hi Henk,

Something in the client domain has to manage the client subscriber-ids 
for each device to ensure that they are unique, e.g. so that one NMS 
(e.g. to subscribing to syslog notifications) doesn't overwrite the 
subscriptions for another NMS (e.g. subscribing to traffic data rates).

Using strings, it seems like it easy to come up with a scheme to 
partition these, e.g. "syslog-xxx" vs "datarate-xxx".

Obviously it is still possible to come up with a unique scheme to 
partition numerical ids, but that naively appears to be more hassle to 
manage, or the client needs a central server to allocate unique 
subscription ids for each given device.  Adding a description statement 
partially helps from a debug perspective, but doesn't remove the 
requirement to allocate unique ids in the first place.

Thanks,
Rob

On 19/10/2017 15:08, Henk Birkholz wrote:
> in the scenario you illustrate, why would you want to do a search by 
> the "additional leaf" and create that "extra burden on all clients"? 
> Why not just use the numeric key? This still leaves me puzzled. It 
> would be like google'ing me via my description rather than my name?
>
> Yes, I agree, that would be burdensome, but why would you do that in 
> the first place?
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Oct 2017 16:36:32 +0000

Hi Carsten,

In this discussion regarding the subscription identifier being a
string rather than an integer, I'm wondering if CBOR is able to
optimize the strings internally, by using a session-level table
that maps strings to integers, such that integers are actually
being sent most of the time in a notification stream?

Thanks,
Kent

Grüße, Carsten

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=XlgqkaSXpFz-mGE6AYKpCJbA8kAczWXlgPglmHZ_bSQ&s=K06Y1fTsx6MLuRV11HROun0_N9gClrbbMh0Q7lVpRHg&e=
> 
> -- 
> Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-2Duniversity.de_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=XlgqkaSXpFz-mGE6AYKpCJbA8kAczWXlgPglmHZ_bSQ&s=sT_XRjdJvlybfKMLFpuv2XWf_coK66wo-bMOMSsXiMw&e=>
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=XlgqkaSXpFz-mGE6AYKpCJbA8kAczWXlgPglmHZ_bSQ&s=K06Y1fTsx6MLuRV11HROun0_N9gClrbbMh0Q7lVpRHg&e=
> 
> 

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=XlgqkaSXpFz-mGE6AYKpCJbA8kAczWXlgPglmHZ_bSQ&s=K06Y1fTsx6MLuRV11HROun0_N9gClrbbMh0Q7lVpRHg&e=

---

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

Hi Kent,

> being sent most of the time in a notification stream?

We could add various forms of compression to yang-cbor.
Generally, we try to opt for concise forms (doing things in a compact way in the first place) over compression, as the latter involves some processing, usually requiring some copying, and that in turn increases memory requirements.
But we could try to evolve something simple for yang-cbor.
So far we didn’t have a need for that, as SIDs already take care of most of the textstringiness of YANG.
One problem in the COMI environment may also be that the session may not be as clearly delimited as in TCP-based transports.

Grüße, Carsten

---

From: Robert Wilton <[email-masked]>
Date: Fri, 20 Oct 2017 10:39:59 +0100

Hi Eric,

One more thing that I noticed is that the drafts state that XML encoding 
is mandatory, E.g. draft-ietf-netconf-yang-push, sec 3.5 and sort of 
also draft-ietf-netconf-subscribed-notifications sec 4.1

I don't think that it should restrict this.  JSON appears to be 
generally more in vogue than XML, binary encodings may be very desirable 
as well,  and an IOT device might not want to have to support XML if 
they will always use CBOR (or do they implement a different standard in 
that case)?.

Note that this discussion also came up when RESTCONF was being 
standardized, and the final text related to this in RFC 8040 is:

    Content is encoded in either JSON or XML format.  A server MUST
    support one of either XML or JSON encoding.  A server MAY support
    both XML and JSON encoding.  A client will need to support both XML
    and JSON to interoperate with all RESTCONF servers.

Perhaps a similar approach would work for these drafts as well?

Thanks,
Rob

On 19/10/2017 02:12, Eric Voit (evoit) wrote:
>
> Thanks everyone who has commented on 
> draft-ietf-netconf-subscribed-notifications so far during the two week 
> focused review.   I believe the changes discussed on and agreed to on 
> this list so far are embedded in a preliminary version of v06 which is 
> located at:
>
> (Many thanks to Martin.  I do need to triple check to see that I got 
> all of the agreements with Martin covered, but I think I did.)
>
> Summary: to identify the source VRF, do we do (i) a leafref to the 
> ietf-network-instance model, or (ii) use the string data type for 
> route distinguisher and route target as defined in 
> draft-ietf-rtgwg-routing-types.
>
> Recommendation (ii) as this will be far closer to what implementers 
> will be doing for the foreseeable future.  But I could live with (i) 
> even though I am not sure anyone is implementing it (which results in 
> unnecessary vendor augmentations), and it creates an unnecessary 
> dependency on schema mount.
>
> Summary: Should the transport protocol and the encoding should be the 
> same for all configured receivers of a single subscription?
>
> Recommendation: encoding should stay the same for all receivers, but 
> transport should be allow to vary be receiver.  Reasoning:  encoding 
> is a publisher function, and unlikely to vary.  Transport is dependent 
> somewhat on the receiver capabilities, and allowing variation here 
> enables seamless incremental conversion of receivers and the ability 
> to have the same configured subscription-id available to correlate 
> across receivers using different transports.
>
> Summary: I think that this issue is not a barrier to WGLC as the 
> current draft removes any normative reference to the new 
> notification-messages draft, and acknowledges that we should update 
> this document when notification-messages completes.
>
> so much so that my belief is that  this need not be turned into a 
> formal issue.  Look for others’ opinions on the alias and chime in.  
> If anyone else strongly feels “string” is the right way to go, we can 
> - There are comments of Martin’s on this document which will drive 
> some revised content into 
> draft-ietf-netconf-netconf-event-notifications. (Head’s up Alberto ;-)
>
> - I plan on integrating Tim’s suggestion that we have a separate 
> receivers container for configured subscriptions.  As I am not hearing 
> any issues from people (other than a little more complexity) I will 
> add that in tomorrow.
>
> Robert also has an umbrella question on the draft set dependency to 
> notification-messages. (I.e., Not specific to this draft.)  As we have 
> multiple known implementations of YANG push over NETCONF, it will be 
> quite a while before notification-messages solidifies, and we need to 
> chunk this rather large set of work, I am hoping this too resolves 
> quickly.
>
> Thanks,
> Eric
>
> .

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 20 Oct 2017 12:33:29 +0000

From: Robert Wilton, October 20, 2017 5:40 AM

Hi Eric,

One more thing that I noticed is that the drafts state that XML encoding is mandatory, E.g. draft-ietf-netconf-yang-push, sec 3.5 and sort of also draft-ietf-netconf-subscribed-notifications sec 4.1

I don't think that it should restrict this.  JSON appears to be generally more in vogue than XML, binary encodings may be very desirable as well,  and an IOT device might not want to have to support XML if they will always use CBOR (or do they implement a different standard in that case)?.

Note that this discussion also came up when RESTCONF was being standardized, and the final text related to this in RFC 8040 is:

<Eric> I have no problem with this.  Anyone have objections?
Eric

Thanks,
Rob

(4) Martin is also asking that a subscription identifier to be a string rather than an integer.   While this is technically open between Martin & I, I believe the case is very strong for integer  -- so much so that my belief is that  this need not be turned into a formal issue.  Look for others’ opinions on the alias and chime in.  If anyone else strongly feels “string” is the right way to go, we can certainly create an issue to track.

Beyond that:

- There are other minor comments which are hopefully in their last stages with Martin
- There are comments of Martin’s on this document which will drive some revised content into draft-ietf-netconf-netconf-event-notifications. (Head’s up Alberto ;-)
- I plan on integrating Tim’s suggestion that we have a separate receivers container for configured subscriptions.  As I am not hearing any issues from people (other than a little more complexity) I will add that in tomorrow.

Thanks,
Eric

.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 20 Oct 2017 16:01:40 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> One more thing that I noticed is that the drafts state that XML
> encoding is mandatory, E.g. draft-ietf-netconf-yang-push, sec 3.5 and
> sort of also draft-ietf-netconf-subscribed-notifications sec 4.1
> 
> generally more in vogue than XML, binary encodings may be very
> desirable as well, and an IOT device might not want to have to support
> XML if they will always use CBOR (or do they implement a different
> standard in that case)?.
> 

I think that since this document is transport-agnostic, it shouldn't
mandate any specific encoding at all.  If a server in a constrained
environment only implements CBOR, that should be fine, right?

In fact, I think we should move all transport-specific text and
definitions to the transport-specific documents.  This would mean that
also draft-ietf-netconf-netconf-event-notifications gets normative
contents.

On a related note, I previously wrote that the encoding leaf should be
moved down and specified together with the transport.  I have been
thinking some more about this.  I still think that encoding should be
moved down, since different protocols support different encodings (and
some just have a single encoding).  I wonder if we shouldn't use the
design pattern of using a list of receivers with choice for the
transports.  See
https://tools.ietf.org/html/draft-schoenw-netmod-yang-pattern-00#page-6
for an example (yes the draft is expired).

/martin

> transport should be allow to vary be receiver.  Reasoning: encoding is
> a publisher function, and unlikely to vary.  Transport is dependent
> Look for others’ opinions on the alias and chime in.  If anyone else
> strongly feels “string” is the right way to go, we can certainly
> - There are other minor comments which are hopefully in their last
> - stages with Martin
> - There are comments of Martin’s on this document which will drive some
> - revised content into
> - draft-ietf-netconf-netconf-event-notifications. (Head’s up Alberto ;-)
> - receivers container for configured subscriptions.  As I am not hearing
> - any issues from people (other than a little more complexity) I will
> - add that in tomorrow.
>

---

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

Hi Martin,

There are interesting elements in the proposal of a design pattern of having a transport specific list under each receiver.   So went ahead and built it.  See:

Model:
https://github.com/netconf-wg/rfc5277bis/blob/master/ietf-subscribed-notifications-Martin%402017-10-20.yang
Tree:
https://github.com/netconf-wg/rfc5277bis/blob/master/Martin-tree.txt

The benefits:
- should be fewer places for configuration errors
- default ports for transport 
- gets rid of the identities for transports

The costs:
- Tree is 23 lines bigger
- Model is 33 lines bigger
- For read-only access to each receiver and its operational counter objects for a subscription (even a dynamic one) you need to know the transport
- Any additional transports (like CBOR) each requires multiple augmentations

I am absolutely good with either solution, but the model is already big and complex.  And this design pattern does add to that.

More thoughts in-line...

> From: Martin Bjorklund, October 20, 2017 10:02 AM
> 
> I think that since this document is transport-agnostic, it shouldn't mandate any
> specific encoding at all.  If a server in a constrained environment only
> implements CBOR, that should be fine, right?

Works for me.   I was on that path too based on the thread with Kent last night.
 
> In fact, I think we should move all transport-specific text and definitions to the
> transport-specific documents.  This would mean that also draft-ietf-netconf-
> netconf-event-notifications gets normative contents.

Yes, any transport specific items not in YANG model should be in those documents.  Two exceptions are (1) examples needing to include transport for completeness, and (2) elements of the YANG model.

Eric
 
> On a related note, I previously wrote that the encoding leaf should be moved
> down and specified together with the transport.  I have been thinking some
> more about this.  I still think that encoding should be moved down, since
> different protocols support different encodings (and some just have a single
> encoding).  I wonder if we shouldn't use the design pattern of using a list of
> receivers with choice for the transports.  See
> > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netcon
> > f-subscribed-notifications-06.txt (Many thanks to Martin.  I do need
> > to triple check to see that I got all of the agreements with Martin
> > covered, but I think I did.)
> >
> > some

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 27 Oct 2017 19:09:29 +0000

> > From: Robert Wilton, October 20, 2017 5:40 AM
...
> netconf-event-notifications gets normative contents.

This makes sense.  But I do think there is one useful tweak for the definition of the RPC for establish subscription:

rpc establish-subscription {
    input {
      uses subscription-policy {
        refine "encoding" {
          mandatory false;
          description
            "The type of encoding for the subscribed data. If not
            included as part of the RPC, the encoding MUST be set by the 
            publisher to be the encoding used by this RPC.";
        }
      }
    }

With this, I believe the encoding need only be provided when it differs from the current one used to encode the establish-subscription message.

Eric