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

["Eric Voit (evoit)" <[e-mail]>]

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