Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 1 Oct 2019 16:00:01 -0700

Hi Balasz,

I have reviewed your preliminary next version of the document (-05), and have the following comments. Some of these comments might be duplicates or overlap with comments provided by others.

Minor issues:

- Please fix the sub-title of the draft as it refers to -04 version of the document.

- Can we get a consistent view in the draft using either publisher/subscriber or server/client in the document. I see Publisher/Receiver, client/management combinations also used in the document.

- Can we use 'on-change consistently' in the document. I see both "on-change" and "on change”

- I still see reference to Yang instead of YANG in the document.

- Remove Section 6.

Remaining comments:

Introduction

s/identify for which objects/identify which objects

OLD:

   During NMS implementation for any
   functionality that depends on the notifications the information about
   on change notification capability is needed.

NEW:

   A NMS implementation that wants to support notifications, needs the information about
   on-change notification capability.

Can you explain the following statement. What does it mean for the “network node to be ready”? Exchange capability information? Also, if that capability is exchanged at run-time what would the subscriber do? Per your explanation, the “implementation time” capability requires an implementation, and therefore an implementation not knowing it would have to discard this capability??? 

  "If the information is
   not documented in a way available to the NMS designer, but only as
   instance data from the network node once it is deployed, the NMS
   implementation will be delayed, because it has to wait for the
   network node to be ready."

The rest of the explanation on that paragraph of not having a ”correctly configured network node available to retrieve data” could use an example. I am not clear in what way an incorrectly configured network node would create a problem specifically in this situation, other than the fact that any incorrectly configured node is a problem.

Thanks.

> On Sep 30, 2019, at 2:20 AM, Balázs Lengyel <[email-masked]> wrote:
> 
> Hello,
> Here is a preliminary next version (not submitted yet). See also below.
> Regards Balazs
>  
> From: Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> 
> Sent: 2019. szeptember 27., péntek 21:42
> To: Balázs Lengyel <[email-masked] <mailto:[email-masked]>>; Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>>; Alexander Clemm <[email-masked] <mailto:[email-masked]>>; Benoit Claise (bclaise) <[email-masked] <mailto:[email-masked]>>
> Cc: Netconf <[email-masked] <mailto:[email-masked]>>
> Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities
>  
> Hi Balazs,
>  
> Some more thoughts in-line.   I cut out those I think closed.
>  
> From: Balázs Lengyel <[email-masked] <mailto:[email-masked]>> 
> Sent: Friday, September 27, 2019 8:48 AM
> To: Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>>; Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>>; Alexander Clemm <[email-masked] <mailto:[email-masked]>>; Benoit Claise (bclaise) <[email-masked] <mailto:[email-masked]>>
> Cc: Netconf <[email-masked] <mailto:[email-masked]>>
> Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities
>  
> Thanks for the comments. See answers below. 
> I hope the group will be ok with using the term publisher instead of server. IMHO it is clearer as the client server relationship can be reversed e.g. for https notification transport.
> Balazs
>  
> From: Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> 
> Sent: 2019. szeptember 24., kedd 23:15
> To: Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>>; Balázs Lengyel <[email-masked] <mailto:[email-masked]>>; Alexander Clemm <[email-masked] <mailto:[email-masked]>>; Benoit Claise (bclaise) <[email-masked] <mailto:[email-masked]>>
> Cc: Netconf <[email-masked] <mailto:[email-masked]>>
> Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities
>  
> Here are some comments...
>  
> On-change Notification Capability: Is this different from support for RFC-8641 feature "on-change"?  If they are the same, it might be possible to remove the term.  Especially as this term is used inconsistently.
> BALAZS: In RFC 8641 on-change is not defined as a capability. It is used for many more things (e.g. On-change subscription,  trigger condition, type of push updates, a feature.) In this draft the on change capability is just the servers capability to send on-change notification globally, for a specific datastore or a specific data node. Description will be reworded.
> <Eric> It will be good to see the reword.   I still am not clear how this different from the RFC-8641 feature "on-change", along with this feature being associated with specific nodes.  
> BALAZS2: 
> On-change Notification Capability: The capability of the server to
>    send on-change notifications for a specific datastore or a specific
>    data node.
>  
>  
> Section 3
>  
> Paragraph 2, bullet 2: Instead of  "amount of notifications the server can send out", do you mean "the minimum periodicity of updates which a server can send out for an object"
> BALAZS: That too, but also the max-objects-per-update. I was told not to repeat information in the main text and in the YANG module, so I tried to find a wording that covers both. Also  its not always the minimum times. Some servers support  a specific set of times, not a anything over a minimum.
> <Eric> Ok, so this bullet is a bucket of various types of information.  Which is fine with me.
>  
>  
> Paragraph 2, bullets 3 & 4: I don't think these should be indented as bullets are they are more about proper behavior of a correctly populated model.
> BALAZS: I don’t really understand this comment.  Please explain.
> <Eric> Looking at the text, bullets 3 is written to say how capabilities value can be set (i.e., how) rather than that they can be set for different levels (i.e., what).  Getting consistency so that the bullets are all 'how' or all 'what' items would help readability.  
> BALAZS2: OK, I get it. You are right, to be corrected.
>  
>  
> Paragraph 3, bullets 2: why isn't SHALL instead MUST?   Also, shouldn't this point out that both NETCONF and RESTCONF MUST be supported if on-change is advertised, and this draft is supported?
> BALAZS: As I understand RFC 2119 MUST and SHALL both mean the same, but I will change to MUST. No I do not want to mandate implementing both Netconf AND Restconf. IMO a server with just Netconf would work just fine; or maybe I misunderstand your comment?
> <Eric> The second part of my comment was about ensuring that IF this model was available, and the publisher supports both RFC-8640 & draft-ietf-netconf-restconf-notif, then this specification MUST be able to push changes over both NETCONF and RESTCONF.    Thinking more, this is actually a generic question which is likely already answered: how do you know which models are supported for which transports.   As advertisement is by transport, I withdraw this question.  
> BALAZS2: Some implementations have a yang extension statement to specify whether  a model is visible on specific interfaces
>  
> Section 4
>  
> I suspect that you will need to do a security analysis per YANG object.   This has been done the other YANG push family.
> BALAZS: The full module is readOnly and not sensitive or private in any manner.  The security text for the readOnly parts of YangPush is the exact same text: not very informative, but gives you the illusion of security awareness.
> <Eric> You can ignore my comment.  In doing RFC-8639, I needed to put in read/write analysis for each object.  And this did sometime include the risks of internally setting values which were read-only from the model.  Perhaps this will not be required during later draft reviews in the publication process.
>  
> I suspect that manipulating the reporting intervals could have some security implications.   E.g., a hacker could push up the damping period or periodic interval to a level where the information they are changing then becomes invisible to a monitoring system.
> BALAZS: The full YAM is read-only so manipulating the data is not a concern.
> <Eric> Per my previous point, if the IETF process says you don't need to highlight such possibilities, then I am good.
> BALAZS2:
> In rfc8639 the text says for readOnly data nodes something like: 
> If access control is not properly configured, can expose
>       system internals to those who should not have access to this
>       information.
> That is true for any bit of data, so I do not understand what information does it add. It does not hurt, so I will add the same sentence to my draft.
>  
> If you have something else in mind please describe the attack method that I should mention.
> </Eric>
>  
> Thanks, 
> Eric 
>  
>  
> From: netconf <[email-masked] <mailto:[email-masked]>> On Behalf Of Mahesh Jethanandani
> Sent: Tuesday, September 24, 2019 1:50 PM
> To: Netconf <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities
>  
> We were supposed to have closed on the WGLC today. However, between the document becoming a WG item and it going into LC, we have not received too many comments on the draft. As such, we are extending the LC by another week. Please review the draft and provide any comments you might have.
>  
> Mahesh & Kent (as co-chairs)
>  
>  
> 
> On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Authors have published -04 <https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-04> version of the draft, which addresses comments they received in IETF 105. If you provided comments please check to make sure your comments have been addressed. At this point, the authors believe that the document is ready for WGLC.
>  
> This therefore starts a two week LC, ending on September 24th. Please provide any technical comments you might have on the document. If you believe the document is not ready for LC, please state your reasons.
>  
> We will issue a IPR poll separately. 
>  
> Mahesh & Kent (as co-chairs)
>  
>  
>  
>  
> <draft-ietf-netconf-notification-capabilities-05b.txt>

Mahesh Jethanandani
[email-masked]

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 2 Oct 2019 13:42:53 +0000

From: Mahesh Jethanandani <[email-masked]> 
Sent: 2019. október 2., szerda 1:00
To: Balázs Lengyel <[email-masked]>
Cc: Eric Voit (evoit) <[email-masked]>; Alexander Clemm <[email-masked]>; Benoit Claise <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Hi Balasz,

Minor issues:

BALAZS: OK, done

BALAZS: I changed to use subscriber/publisher except in cases where we speak about datastores and functionality based on

get, getconfig operations. In this latter case it is really the server functionality that is discussed.

BALAZS:OK,  Found 1 “on change” replaced with “on-change”

BALAZS: OK, corrected.

- Remove Section 6.

BALAZS: OK

Remaining comments:

Introduction

BALAZS: OK

OLD:

NEW:

BALAZS: OK

Can you explain the following statement. What does it mean for the “network node to be ready”? 

BALAZS: In Ericsson and our customers usually start designing the management system for a node even before it is ready or fully implemented or released or handed over to the customer. That’s what I to shorten to “ready”.

Exchange capability information? Also, if that capability is exchanged at run-time what would the subscriber do? Per your explanation, the “implementation time” capability requires an implementation, and therefore an implementation not knowing it would have to discard this capability??? 

  "If the information is

BALAZS: The point is that if you do not have  the capabilities documented in implementation-time and available off-line, 

you need a fully implemented live server/publisher network node to read that information from. A NMS can handle 10-100 node types. To get this information from each you would need these network nodes up and running in your lab. Usually you also need to configure the network node to get access to its Netconf interface/CLI. In some cases specific information is only available if the correct licenses are installed for the network node. 

So to get the information from a live server in run-time, you may need to

1.	Have the network node available
2.	Need to configure the node to some level
3.	Need authentication information for it
4.	Need licenses for it.

Thanks.

On Sep 30, 2019, at 2:20 AM, Balázs Lengyel <[email-masked] <mailto:[email-masked]> > wrote:

Hello,

Regards Balazs

From: Eric Voit (evoit) < <mailto:[email-masked]> [email-masked]> 
Sent: 2019. szeptember 27., péntek 21:42
To: Balázs Lengyel < <mailto:[email-masked]> [email-masked]>; Mahesh Jethanandani < <mailto:[email-masked]> [email-masked]>; Alexander Clemm < <mailto:[email-masked]> [email-masked]>; Benoit Claise (bclaise) < <mailto:[email-masked]> [email-masked]>
Cc: Netconf < <mailto:[email-masked]> [email-masked]>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Hi Balazs,

From: Balázs Lengyel < <mailto:[email-masked]> [email-masked]> 
Sent: Friday, September 27, 2019 8:48 AM
To: Eric Voit (evoit) < <mailto:[email-masked]> [email-masked]>; Mahesh Jethanandani < <mailto:[email-masked]> [email-masked]>; Alexander Clemm < <mailto:[email-masked]> [email-masked]>; Benoit Claise (bclaise) < <mailto:[email-masked]> [email-masked]>
Cc: Netconf < <mailto:[email-masked]> [email-masked]>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Balazs

From: Eric Voit (evoit) < <mailto:[email-masked]> [email-masked]> 
Sent: 2019. szeptember 24., kedd 23:15
To: Mahesh Jethanandani < <mailto:[email-masked]> [email-masked]>; Balázs Lengyel < <mailto:[email-masked]> [email-masked]>; Alexander Clemm < <mailto:[email-masked]> [email-masked]>; Benoit Claise (bclaise) < <mailto:[email-masked]> [email-masked]>
Cc: Netconf < <mailto:[email-masked]> [email-masked]>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

BALAZS2: 

   data node.

Section 3

 

 

Section 4

BALAZS2:

      information.

</Eric>

Thanks, 

Eric 

From: netconf < <mailto:[email-masked]> [email-masked]> On Behalf Of Mahesh Jethanandani
Sent: Tuesday, September 24, 2019 1:50 PM
To: Netconf < <mailto:[email-masked]> [email-masked]>
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

 

On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani < <mailto:[email-masked]> [email-masked]> wrote:

Authors have published  <https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-04> -04 version of the draft, which addresses comments they received in IETF 105. If you provided comments please check to make sure your comments have been addressed. At this point, the authors believe that the document is ready for WGLC.

 

Mahesh Jethanandani

[email-masked] <mailto:[email-masked]>

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 2 Oct 2019 16:52:54 +0000

On Sep 30, 2019, at 05:20, Balázs Lengyel <balazs.lengyel=[email-masked]<mailto:balazs.lengyel=[email-masked]>> wrote:

Hello,

I have reviewed this version and looked at others’ comments.  I think this document is ready (based on the addressing of others’ comments), and I support its goals.  This will make the consumption of telemetry much easier for operators.

Joe

Regards Balazs

From: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>
Sent: 2019. szeptember 27., péntek 21:42
To: Balázs Lengyel <[email-masked]<mailto:[email-masked]>>; Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>; Alexander Clemm <[email-masked]<mailto:[email-masked]>>; Benoit Claise (bclaise) <[email-masked]<mailto:[email-masked]>>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Hi Balazs,

From: Balázs Lengyel <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 27, 2019 8:48 AM
To: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>; Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>; Alexander Clemm <[email-masked]<mailto:[email-masked]>>; Benoit Claise (bclaise) <[email-masked]<mailto:[email-masked]>>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

From: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>
Sent: 2019. szeptember 24., kedd 23:15
To: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>; Balázs Lengyel <[email-masked]<mailto:[email-masked]>>; Alexander Clemm <[email-masked]<mailto:[email-masked]>>; Benoit Claise (bclaise) <[email-masked]<mailto:[email-masked]>>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Section 3

Section 4

Thanks,
Eric

From: netconf <[email-masked]<mailto:[email-masked]>> On Behalf Of Mahesh Jethanandani
Sent: Tuesday, September 24, 2019 1:50 PM
To: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

Authors have published -04<https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-04> version of the draft, which addresses comments they received in IETF 105. If you provided comments please check to make sure your comments have been addressed. At this point, the authors believe that the document is ready for WGLC.

<draft-ietf-netconf-notification-capabilities-05b.txt>_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 2 Oct 2019 12:17:41 -0700

This concludes the LC on the draft. Authors, please address all the comments provided as part of LC, and post the updated draft. 

Thanks. 

Mahesh & Kent. 

> On Sep 24, 2019, at 10:50 AM, Mahesh Jethanandani <[email-masked]> wrote:
> 
>> On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani <[email-masked]> wrote:
>> 
>> Authors have published -04 version of the draft, which addresses comments they received in IETF 105. If you provided comments please check to make sure your comments have been addressed. At this point, the authors believe that the document is ready for WGLC.
>>

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 3 Oct 2019 14:20:27 +0000

From: Rob Wilton (rwilton) <[email-masked]> 
Sent: 2019. szeptember 30., hétfő 16:45
To: Mahesh Jethanandani <[email-masked]>; Netconf <[email-masked]>; Balázs Lengyel <[email-masked]>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Hi,

I have reviewed version -05b of this document.

I am supportive of this document, and its general approach of making subscription capability information available both online and offline.  I believe that this information is valuable to making YANG-Push more usable.

A few comments:

1.	Terminology and Introduction.  I wasn’t sure whether “implementation-time information” is the best description, or whether “offline information” would be a better description.   I believe that the key is that the information is available offline without requiring access to all the network devices.  Although I can see that providing this information at implementation time is useful and should be RECOMMENDED, I don’t think that it should be a MUST/SHALL (e.g. as per section 3). 

BALAZS: I would like to keep the term “implementation-time”, as we had a number of debates about the correct term and this is one term people seemed to agree upon.  In practice it is often important to provide the information early, before the network node is fully implemented as NMS planning and design often begins early as well. In practice the capabilities are decided in implementation time.

2.	Another benefit of having information available offline is that if there are classes of devices running the same software and hardware then they should all have the same capabilities without having to check each and every one.  To this end, it would be nice if there was some sort of simple checksum mechanism that could be used to ensure that the information stored in the instance-data file exactly matches the equivalent information provided by the server.  This would allows NMS implementations to be coded to the instance-data document, and then just validate that the checksums match those provided by the server without having to fetch and check that a portion of the data tree matches.  As a side note – YANG packages has a similar requirement.

BALAZS: This seems like a requirement to implement an Entity-tag similar to   <https://tools.ietf.org/html/rfc8040#section-3.5.2> https://tools.ietf.org/html/rfc8040#section-3.5.2 but with a deterministic algorithm to generate the tag value. While the idea is interesting/worthwhile, IMHO it should be handled in a generic manner, not for each YANG module separately. Also I was instructed to remove the entity tag from draft-ietf-netmod-yang-instance-file-format.

3.	Section 3, by “formal”, do you mean “machine readable”?  Otherwise expanding what is meant by formal might be useful.

BALAZS: OK, changed text

4.	Section 3, instead of “amount of notifications” would “throughput of notification data” be better? 

BALAZS: As you wish, changed text.

In terms of the YANG model, I think that it is possible to design this in a slightly more regular (and arguably simpler) way:

*	Rename “datastore-subscription-throughput-capabilities grouping” to “subscription-throughput-capabilities” (since the grouping is also used at the subscription level)

BALAZS: OK, renamed

BALAZS:: IMHO the other changes look more simple, but will actually make the model more complicated.

*	Add “on-change-supported” leaf to “subscription-throughput-capabilities” grouping, but change its type to an enum of “all-nodes, config-only, state-only” – this could then work in a fully hierarchical way.  (I.e. the existing on-change-supported-for-config, on-change-supported-for-state , on-change-supported could be removed).

BALAZS: The enum will need much more explanation e.g. what does it mean to have the “config-only” value on a config=false data node? It can be explained, it will just need more text. 

*	Instead of having a set of “datastore” level parameters, could these just be expressed as the set of parameters that apply to “/” within a datastore (e.g. as described in NACM YANG module “leaf path“)?  I.e. given that you support hierarchical paths within a datastore, it just means that you need two levels, per device and per datastore.

BALAZS: It looks simpler, but we would have to have longer explanations:

*	The “/” is not well defined or well known, so its use must be described
*	The extra case when there is no per-node-capabilities list-entry needs to be explained/specified

*	Ideally, it would be better to have a dependency on RFC6991-bis for node-instance-identify rather than on NACM.  Although I guess that you may not want to delay this RFC.

BALAZS: Agreed, but please no delay. 

*	Currently “leaf on-change-supported” is marked as mandatory true, but I’m not sure why it should be so.

BALAZS: OK. made it mandatory false; There is a use-case where the per leaf dampening period needs to be specified, but the on-change-supported is inherited from the containing parent/datastore.

*	Is “max-objects-per-update” optional.  What if the server doesn’t have any hard limit - can they just not return a value here?  If so, perhaps assigning a default value of uint32_max might make sense?

BALAZS: It is optional. If there is no hard limit or the limit is not known the leaf must be absent. The module description include the text:

      Any capability value MAY be absent ... if the publisher is not capable of 

      providing a value.

In the security section, are these capabilities sensitive information?  E.g. could it be used by an attacker to more effectively DDOS a server (by knowing which paths to target subscriptions towards)?

BALAZS: IMHO the information is not security sensitive. The minimum dampening period and minimum-update-period can be used to find schema sections that might generate more notifications, but this is really a corner-case and we usually don’t describe such details. However the security section now includes:

         The Network Configuration Access Control Model (NACM) [RFC8341] 

         provides the means to restrict access for particular NETCONF or 

         RESTCONF users to a preconfigured subset of all available NETCONF or 

         RESTCONF protocol operations and content. 

         If access control is not properly configured, it can expose

         information.

Thanks,

Rob

From: netconf <[email-masked] <mailto:[email-masked]> > On Behalf Of Mahesh Jethanandani
Sent: 24 September 2019 18:50
To: Netconf <[email-masked] <mailto:[email-masked]> >
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

 

On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]> > wrote:

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 3 Oct 2019 14:48:03 +0000

From: Kent Watsen <[email-masked]> 
Sent: 2019. szeptember 30., hétfő 22:03
To: Balázs Lengyel <[email-masked]>
Cc: Eric Voit (evoit) <[email-masked]>; Mahesh Jethanandani
<[email-masked]>; Alexander Clemm <[email-masked]>; Benoit Claise
<[email-masked]>; [email-masked]
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

In reviewing the draft, I don't see where the file format is defined.    I
understand the module defining a 'container' for protocol-accessible nodes,
but shouldn't it define an 'sx:structure' for the file format?  I suggest
moving the contents of the "datastore-subscription-capabilities" container
to a 'grouping' and then have both the container and an 'sx:structure' use
that grouping.

BALAZS2: This drafts does not want to define a file format. It intends to
use the "generic" file format defined in
draft-ietf-netmod-yang-instance-file-format. IMHO the whole aim of
draft-ietf-netmod-yang-instance-file-format is to avoid individual drafts
defining file formats.

On the below:

I suspect that you will need to do a security analysis per YANG object.
This has been done the other YANG push family.

BALAZS: The full module is readOnly and not sensitive or private in any
manner.  The security text for the readOnly parts of YangPush is the exact
same text: not very informative, but gives you the illusion of security
awareness.

I suspect that manipulating the reporting intervals could have some security
implications.   E.g., a hacker could push up the damping period or periodic
interval to a level where the information they are changing then becomes
invisible to a monitoring system.

 

The draft should say something like:

1. All protocol-accessible are read-only and cannot be modified.  The nature
of the read-only data is not deemed to be sensitive in a way necessitating
access-control restrictions (e.g., NACM) beyond the client being
authenticated.

BALAZS2: OK,  Updated with first part, but Rob has asked for an extra
sentence about the dangers of revealing read-only data, I added that too.

"All protocol-accessible data are read-only and cannot be modified. 

        The data in this module is not security sensitive.

        Access control may be configured, to avoid exposing 

        the read-only data."

2. When a file format, the protection afforded by a mutually authenticated
transport protocol.  Protection of the data must be performed manually, so
as to ensure that the data is neither seen nor modified in transit.

Reword as needed.

BALAZS2: Agreed. This is part of normal file handling, transport. So I
reworded this to:

"When that data is in file format, data should be protected against 

        modification or unauthorized access using normal file handling and 

        secure and mutually authenticated file transport mechanisms."

Kent // contributor

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 3 Oct 2019 16:12:52 +0000

Hi Balazs,

From: Balázs Lengyel <[email-masked]>
Sent: 03 October 2019 15:20
To: Rob Wilton (rwilton) <[email-masked]>; Mahesh Jethanandani <[email-masked]>; Netconf <[email-masked]>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

From: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Sent: 2019. szeptember 30., hétfő 16:45
To: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>; Netconf <[email-masked]<mailto:[email-masked]>>; Balázs Lengyel <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Hi,

A few comments:

1.       Terminology and Introduction.  I wasn’t sure whether “implementation-time information” is the best description, or whether “offline information” would be a better description.   I believe that the key is that the information is available offline without requiring access to all the network devices.  Although I can see that providing this information at implementation time is useful and should be RECOMMENDED, I don’t think that it should be a MUST/SHALL (e.g. as per section 3).
BALAZS: I would like to keep the term “implementation-time”, as we had a number of debates about the correct term and this is one term people seemed to agree upon.  In practice it is often important to provide the information early, before the network node is fully implemented as NMS planning and design often begins early as well. In practice the capabilities are decided in implementation time.
[RW]
OK.  But I’m not really convinced that all vendors will be able to provide this information at implementation time.  I would normally expect a vendor to delay providing this information until the implementation is complete, they have tested it and verified that they can make the subscription guarantees that are being stated.  I think that a common case would be provide this information when the software is available (which could be ahead of the hardware availability).  But if you want to call it “implementation time” then I can live with that.
In section 3, I think

   The information SHALL be provided in two ways both following the
   ietf-notification-capabilities module:

should be:

   The information SHOULD be provided in two ways both following the
   ietf-notification-capabilities module:

2.       Another benefit of having information available offline is that if there are classes of devices running the same software and hardware then they should all have the same capabilities without having to check each and every one.  To this end, it would be nice if there was some sort of simple checksum mechanism that could be used to ensure that the information stored in the instance-data file exactly matches the equivalent information provided by the server.  This would allows NMS implementations to be coded to the instance-data document, and then just validate that the checksums match those provided by the server without having to fetch and check that a portion of the data tree matches.  As a side note – YANG packages has a similar requirement.
BALAZS: This seems like a requirement to implement an Entity-tag similar to  https://tools.ietf.org/html/rfc8040#section-3.5.2 but with a deterministic algorithm to generate the tag value. While the idea is interesting/worthwhile, IMHO it should be handled in a generic manner, not for each YANG module separately. Also I was instructed to remove the entity tag from draft-ietf-netmod-yang-instance-file-format.
[RW]
I agree that it is better to handle generically, although in the YANG packages case, I don’t think that this would work, because not everything is part of an instance-data document (e.g. a checksum for a module).  The deterministic algorithm that the packages draft is currently using is a SHA-256 hash.

-          Rename “datastore-subscription-throughput-capabilities grouping” to “subscription-throughput-capabilities” (since the grouping is also used at the subscription level)
BALAZS: OK, renamed
BALAZS:: IMHO the other changes look more simple, but will actually make the model more complicated.
[RW]
So, the current tree output is this:

module: ietf-notification-capabilities
  +--ro datastore-subscription-capabilities
     +--ro (update-period)?
     |  +--:(minimum-update-period)
     |  |  +--ro minimum-update-period?     uint32
     |  +--:(supported-update-period)
     |     +--ro supported-update-period*   uint32
    +--ro max-objects-per-update?          uint32
     +--ro minimum-dampening-period?        uint32 {yp:on-change}?
     +--ro datastore-capabilities* [datastore]
        +--ro datastore                          union
        +--ro (update-period)?
        |  +--:(minimum-update-period)
        |  |  +--ro minimum-update-period?       uint32
        |  +--:(supported-update-period)
        |     +--ro supported-update-period*     uint32
        +--ro max-objects-per-update?            uint32
        +--ro minimum-dampening-period?          uint32 {yp:on-change}?
        +--ro on-change-supported-for-config?    boolean {yp:on-change}?
        +--ro on-change-supported-for-state?     boolean {yp:on-change}?
        +--ro per-node-capabilities* [node-selector]
           +--ro node-selector             nacm:node-instance-identifier
           +--ro (update-period)?
           |  +--:(minimum-update-period)
           |  |  +--ro minimum-update-period?    uint32
           |  +--:(supported-update-period)
           |     +--ro supported-update-period*  uint32
           +--ro max-objects-per-update?         uint32
           +--ro minimum-dampening-period?       uint32 {yp:on-change}?
           +--ro on-change-supported             boolean {yp:on-change}?

The model that I proposed would look like this:

module: ietf-notification-capabilities
  +--ro datastore-subscription-capabilities
     +--ro (update-period)?
     |  +--:(minimum-update-period)
     |  |  +--ro minimum-update-period?     uint32
     |  +--:(supported-update-period)
     |     +--ro supported-update-period*   uint32
    +--ro max-objects-per-update?          uint32
     +--ro minimum-dampening-period?        uint32 {yp:on-change}?
     +--ro on-change-supported?             Enum of (config|state|both)
     +--ro datastore-capabilities* [datastore]
        +--ro datastore                          union
        +--ro per-node-capabilities* [node-selector]
           +--ro node-selector             nacm:node-instance-identifier
           +--ro (update-period)?
           |  +--:(minimum-update-period)
           |  |  +--ro minimum-update-period?    uint32
           |  +--:(supported-update-period)
           |     +--ro supported-update-period*  uint32
           +--ro max-objects-per-update?         uint32
           +--ro minimum-dampening-period?       uint32 {yp:on-change}?
           +--ro on-change-supported?            Enum of (config|state|both)

The code interacting with this is more generic , with less corner cases.

But I think that you could go a step further and define it like this, allowing (datastore=’all’ + node-selector = ‘/’) to define the default global capabilities.  Any capabilities for a specific datastore is more specific than “all”.  Capabilities for a more specific path win over a less specific path.  Personally, I would expect this to be simpler to implement because there are less special cases to handle.

module: ietf-notification-capabilities
  +--ro datastore-subscription-capabilities
     +--ro datastore-capabilities* [datastore]
        +--ro datastore                          union
        +--ro per-node-capabilities* [node-selector]
           +--ro node-selector             nacm:node-instance-identifier
           +--ro (update-period)?
           |  +--:(minimum-update-period)
           |  |  +--ro minimum-update-period?    uint32
           |  +--:(supported-update-period)
           |     +--ro supported-update-period*  uint32
           +--ro max-objects-per-update?         uint32
           +--ro minimum-dampening-period?       uint32 {yp:on-change}?
           +--ro on-change-supported?            Enum of (config|state|both)

-          Add “on-change-supported” leaf to “subscription-throughput-capabilities” grouping, but change its type to an enum of “all-nodes, config-only, state-only” – this could then work in a fully hierarchical way.  (I.e. the existing on-change-supported-for-config, on-change-supported-for-state , on-change-supported could be removed).
BALAZS: The enum will need much more explanation e.g. what does it mean to have the “config-only” value on a config=false data node? It can be explained, it will just need more text.
[RW]
I’m not convinced that this would take that much text to explain … e.g. possibly something like

“On change notifications can be supported for (i) only ‘config: true’ nodes, or (ii) only ‘config: false’ nodes, or (iii) all nodes regardless of the ‘config’ flag”

-          Instead of having a set of “datastore” level parameters, could these just be expressed as the set of parameters that apply to “/” within a datastore (e.g. as described in NACM YANG module “leaf path“)?  I.e. given that you support hierarchical paths within a datastore, it just means that you need two levels, per device and per datastore.
BALAZS: It looks simpler, but we would have to have longer explanations:

o   The “/” is not well defined or well known, so its use must be described
[RW]
But it is defined/used in this way for NACM.  I.e. your model would be more consistent with the approach defined in NACM rather than using a different approach.  I think that you also already need to handle the “/” case anyway, or explicitly indicate that it is not allowed.

o   The extra case when there is no per-node-capabilities list-entry needs to be explained/specified
[RW]
I don’t follow your comment.  I’m proposing changing from a model that has 3 levels of hierarchy (global, per-datastore, per datastore schema subtree) to one that only has 2 (global, per datastore schema subtree).

-          Ideally, it would be better to have a dependency on RFC6991-bis for node-instance-identify rather than on NACM.  Although I guess that you may not want to delay this RFC.
BALAZS: Agreed, but please no delay.
[RW]
Yes, OK.  The plan was to get RFC6991bis done fast, I’m not sure how close that document can be to WG LC.  Perhaps we could check with Juegen?

-          Currently “leaf on-change-supported” is marked as mandatory true, but I’m not sure why it should be so.
BALAZS: OK. made it mandatory false; There is a use-case where the per leaf dampening period needs to be specified, but the on-change-supported is inherited from the containing parent/datastore.
[RW]
Sure.

-          Is “max-objects-per-update” optional.  What if the server doesn’t have any hard limit - can they just not return a value here?  If so, perhaps assigning a default value of uint32_max might make sense?
BALAZS: It is optional. If there is no hard limit or the limit is not known the leaf must be absent. The module description include the text:
      Any capability value MAY be absent ... if the publisher is not capable of
      providing a value.
[RW]
OK.  Then I think that there should be a bit more text about what values mean if they are not specified.  E.g. perhaps the following (if this is the right behaviour for all properties).

Old:
      Any capability value MAY be absent if a more generic capability
      value is already provided or if the publisher is not capable of
      providing a value.

New:
      Any capability value MAY be absent if a more generic capability
      value is already provided or if the publisher is not capable of
      providing a value.  If not provided then it should be
      interpreted that the property is unconstrained.

[RW]
Thinking about this some more, I wonder whether the security section could/should refer back to YANG-Push, which allows a server to reject subscriptions if it would cause the server to become overloaded.

Thanks,
Rob

Thanks,
Rob

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 8 Oct 2019 07:40:45 +0000

Hello Rob,

See below. I only kept the parts we are discussing. I will answer model related issues in a separate mail.

Regards Balazs

From: Rob Wilton (rwilton) <[email-masked]> 
Sent: 2019. október 3., csütörtök 18:13
To: Balázs Lengyel <[email-masked]>; Mahesh Jethanandani <[email-masked]>; Netconf <[email-masked]>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Hi Balazs,

In section 3, I think 

should be:

BALAZS2: OK. But in this case I will need to use SHOULD in the following 2 bullets too.

      providing a value.

[RW] 

Old:

      providing a value.

New:

BALAZS2: Don’t agree. Someone requested earlier and I agreed, that there is a use case where there is actually a limit, just it is not known, or not easily calculated, or changing during time. Anyway IMHO specifying unlimited is not really meaningful. Nothing is unlimited in reality. Also it is explicitly stated that the publisher is allowed to limit individual subscriptions to a lower throughput.

So my view is that if we don’t have a value that means nothing more than that we could not provide a meaningful limit.

         information.

[RW] 

BALAZS2: Kent wanted just to state, not modifiable, not sensitive. I updated this to: 

      All protocol-accessible data are read-only and cannot be modified. 

        the read-only data.

When that data is in file format, data should be protected against 

        secure and mutually authenticated file transport mechanisms.

I hope that will be OK

Thanks,

Rob

Thanks,

Rob

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 Oct 2019 16:01:29 +0000

H Balazs,

> BALAZS2: This drafts does not want to define a file format. It intends to use the “generic” file format defined in draft-ietf-netmod-yang-instance-file-format. IMHO the whole aim of draft-ietf-netmod-yang-instance-file-format is to avoid individual drafts defining file formats.

Okay. I see it in Section 3 now.

> 1. All protocol-accessible are read-only and cannot be modified.  The nature of the read-only data is not deemed to be sensitive in a way necessitating access-control restrictions (e.g., NACM) beyond the client being authenticated.
> BALAZS2: OK,  Updated with first part, but Rob has asked for an extra sentence about the dangers of revealing read-only data, I added that too.
> “All protocol-accessible data are read-only and cannot be modified. 
>         the read-only data.”

Okay.  s/protocol-accessible data/protocol-accessible data nodes/

> 2. When a file format, the protection afforded by a mutually authenticated transport protocol.  Protection of the data must be performed manually, so as to ensure that the data is neither seen nor modified in transit.
> Reword as needed.
> BALAZS2: Agreed. This is part of normal file handling, transport. So I reworded this to:
> “When that data is in file format, data should be protected against 
>         secure and mutually authenticated file transport mechanisms.”

Okay.  The end can be shortened, i.e., just "file handling mechanisms".

Kent // contributor

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 10 Oct 2019 08:37:35 +0000

Hello,

I added  your comments to the upcoming next version of the draft.

Regards Balazs

From: Kent Watsen <[email-masked]> 
Sent: 2019. október 9., szerda 18:01
To: Balázs Lengyel <[email-masked]>
Cc: Eric Voit (evoit) <[email-masked]>; Mahesh Jethanandani <[email-masked]>; Alexander Clemm <[email-masked]>; Benoit Claise <[email-masked]>; [email-masked]
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

H Balazs,

On the below:

 

        the read-only data.”

Reword as needed.

 

Kent // contributor

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 24 Oct 2019 12:25:55 -0700

Balasz has posted an update to the draft that addresses comments received during LC. If you provided comments during that period, please evaluate if your comments have been addressed.

Thanks

Mahesh (and Kent).

> On Oct 2, 2019, at 12:17 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> On Sep 24, 2019, at 10:50 AM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>