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

[Balázs Lengyel <[e-mail]>]

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

 

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

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 <[e-mail] <mailto:[e-mail]> > On Behalf Of Mahesh Jethanandani
Sent: Tuesday, September 24, 2019 1:50 PM
To: Netconf <[e-mail] <mailto:[e-mail]> >
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 <[e-mail] <mailto:[e-mail]> > 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)