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

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 10 Sep 2019 15:39:26 -0700

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)

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 12 Sep 2019 12:42:59 +0000

I believe this document is ready to move forward. I have checked that my comments have been addressed in the latest rev.

Regards,
Reshad.

From: netconf <[email-masked]> on behalf of Mahesh Jethanandani <[email-masked]>
Date: Tuesday, September 10, 2019 at 6:40 PM
To: Netconf <[email-masked]>
Subject: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

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.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 24 Sep 2019 19:50:14 +0200

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.

> 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: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 24 Sep 2019 21:14:49 +0000

Here are some comments...

Section 1: Terminology

YANG-Push is the RFC-8641 term rather than Yang-Push.   Both variants are used 
in this document

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.

Implementation-time information is used twice in the document, but without the 
dash

Run-time information is used once.  And the definition refers to the 
availability of information over network management protocols.  Is it worth 
differentiating the term via a linkage to run-time state objects?

Section 2

Paragraph 4: instead of " meaningless (e.g., a temperature gauge changing 0.1 
degrees)", how about "irrelevant to the receiver (e.g., a temperature gauge 
change of 0.1 degrees within a predetermined and acceptable range)"?

Paragraph 6:  instead of "not available early in some document"  how about " 
not documented in a way available to the NMS designer".  Also // from, is/ 
from is

Bullet #1 under Run time information: not sure what is meant by "it does not 
care which data nodes send notification, it will just handle what is 
available.".  Should reword.

Bullet #3: might want to reword: " implementation time capability information 
about the capabilities"

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"

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.

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?

YANG Model

I am not sure why "server" is preferable to "publisher".  The initial 
YANG-Push draft moved to "Publisher" because it is possible for the 
client-server roles to be reversed for some transport protocols.  For example, 
the recent HTTP notif draft might have the receiver fill the HTTP server role. 
I believe it cleaner to revert to the "publisher" terminology.

I do like the tiered structure of specific and generic values.  There are lots 
of good parallels to other YANG work.

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.

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.

Thanks,

Eric

From: netconf <[email-masked]> On Behalf Of Mahesh Jethanandani
Sent: Tuesday, September 24, 2019 1:50 PM
To: Netconf <[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.

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.

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 27 Sep 2019 12:47:40 +0000

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

Section 1: Terminology

YANG-Push is the RFC-8641 term rather than Yang-Push.   Both variants are used in this document

BALAZS: OK. Updated references to RFC and the capitalization to YANG-Push

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.

Implementation-time information is used twice in the document, but without the dash

BALAZS: OK. I corrected the missing dashes. After this the term is used 5 times.

Run-time information is used once.  And the definition refers to the availability of information over network management protocols.  Is it worth differentiating the term via a linkage to run-time state objects?

BALAZS: Sorry but in my count the term appears 9 times. IMHO the duality that the same information is available both during implementation and run-time is an important point, so I would like to keep the term.  Which protocol is used to get the info is not crucial. It could be the CLI. I put Netconf/Restconf there because someone asked for it.

Section 2

Paragraph 4: instead of " meaningless (e.g., a temperature gauge changing 0.1 degrees)", how about "irrelevant to the receiver (e.g., a temperature gauge change of 0.1 degrees within a predetermined and acceptable range)"?

BALAZS: OK, updated

Paragraph 6:  instead of "not available early in some document"  how about " not documented in a way available to the NMS designer".  Also // from, is/ from is

BALAZS: OK, updated. 

Bullet #1 under Run time information: not sure what is meant by "it does not care which data nodes send notification, it will just handle what is available.".  Should reword.

BALAZS: OK, reworded.

Bullet #3: might want to reword: " implementation time capability information about the capabilities"

BALAZS: OK, updated

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.

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.

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?

YANG Model

I am not sure why "server" is preferable to "publisher".  The initial YANG-Push draft moved to "Publisher" because it is possible for the client-server roles to be reversed for some transport protocols.  For example, the recent HTTP notif draft might have the receiver fill the HTTP server role.   I believe it cleaner to revert to the "publisher" terminology.

BALAZS: OK. I agree. Actually had that problem when explaining the HTTPS notification transport in my company. I will start using the term “publisher”.

I do like the tiered structure of specific and generic values.  There are lots of good parallels to other YANG work.

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.

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.

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:

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 27 Sep 2019 19:41:52 +0000

Hi Balazs,

Some more thoughts in-line.   I cut out those I think closed.

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

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

<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.  

Section 3

<Eric> Ok, so this bullet is a bucket of various types of information.  Which is fine with me.

<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.  

<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.  

Section 4

<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.

<Eric> Per my previous point, if the IETF process says you don't need to highlight such possibilities, then I am good.

</Eric>

Thanks, 

Eric

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 30 Sep 2019 09:20:59 +0000

Hello,

Here is a preliminary next version (not submitted yet). See also below.

Regards Balazs

From: Eric Voit (evoit) <[email-masked]> 
Sent: 2019. szeptember 27., péntek 21:42
To: Balázs Lengyel <[email-masked]>; Mahesh Jethanandani <[email-masked]>; Alexander Clemm <[email-masked]>; Benoit Claise (bclaise) <[email-masked]>
Cc: Netconf <[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

Balazs

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

 

BALAZS2: OK, I get it. You are right, to be corrected.

BALAZS2: Some implementations have a yang extension statement to specify whether  a model is visible on specific interfaces

Section 4

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: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 30 Sep 2019 14:44:48 +0000

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).
  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.
  3.  Section 3, by “formal”, do you mean “machine readable”?  Otherwise expanding what is meant by formal might be useful.
  4.  Section 3, instead of “amount of notifications” would “throughput of notification data” be better?

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)
  *   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).
  *   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.
  *   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.
  *   Currently “leaf on-change-supported” is marked as mandatory true, but I’m not sure why it should be so.
  *   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?

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 susbscriptions towards)?

Thanks,
Rob

From: netconf <[email-masked]> On Behalf Of Mahesh Jethanandani
Sent: 24 September 2019 18:50
To: Netconf <[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: Kent Watsen <[email-masked]>
Date: Mon, 30 Sep 2019 20:02:38 +0000

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.

> BALAZS: The full YAM is read-only so manipulating the data is not a concern.

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.

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.

Kent // contributor