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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Balazs,

Please see inline.

> -----Original Message-----
> From: Balázs Lengyel <[e-mail]>
> Sent: 10 March 2020 12:24
> To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]; draft-
> [e-mail]
> Cc: Kent Watsen <[e-mail]>
> Subject: RE: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-
> 11
> 
> -----Original Message-----
> From: Rob Wilton (rwilton) <[e-mail]>
> Sent: 2020. március 9., hétfő 19:34
> To: [e-mail]; Balázs Lengyel <[e-mail]>;
> [e-mail]
> Cc: Kent Watsen <[e-mail]>
> Subject: RE: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-
> 11
> 
<snipped>
> 
> 
> 4. Section 2:
> Please state that the YANG modules are compliant to NMDA.
> BALAZS: What does it mean that a read-only module is NMDA compliant?
> Please
> explain. I would rather not add text that I do not understand.
>
[RW] 
It just means that the model is designed to conform to the architecture, and work with devices that support such an architecture.  E.g. it also means that the modules are not called "foo-state".


 
> 
> 5. YANG model:
> 
> - Does "minimum-dampening-period" only apply of "on-change-supported" is
> enabled.  If so, it might be helpful for the description to state this.  I
> would also put the "on-change-supported" leaf before the
> "minimum-dampening-period" leaf.
> BALAZS: The leaf has an if-feature "yp:on-change" substatement, which
> should
> indicate it is relevant to on-change. I would like to avoid replicating
> too
> much information from the Yang-Push RFC.
> I will rearrange the order of leaves grouping periodic and on-change
> related
> leaves.
> 
> - Does "minimum-dampening-period" only apply if dampening is requested, or
> does that mean that dampening is always required?  The text may need to be
> clarified.  Otherwise, I'm concerned about the on-change notification for
> interface statistics ... that could generate a lot of notifications ;-)
> BALAZS: The answer is not trivial. I can see logic in both cases:
> a) if there is a minimum-dampening-period declared  here, that means that
> dampening MUST always be used. Logical because if the publisher can not
> support a smaller than 5 sec dampening period, it is probably incapable to
> support on-change without dampening.
> b) the publisher MAY support on-change without dampening, but if dampening
> is requested the period MUST NOT be smaller than the
> minimum-dampening-period
> 
> - For both "minimum-dampening-period" and on-change-supported", can
> probably
> remove "data store or" from the description.
> BALAZS: OK
> 
> - Suggest moving "supported-excluded-change-type" above
> periodic-notifications-supported, to keep all the on-change options
> together.  I'm also not particularly keen on the negative enumeration
> values, having them as positive values would seem more normal to me.
> BALAZS: I will rearrange the order of leaves grouping periodic and on-
> change
> related leaves.
> I used negative numbers as the type's union also includes type
> yp:change-type which is an enumeration with implicit value assignment.
> Using
> negative numbers is a way to avoid clashing with these implicitly assigned
> numbers.
[RW] 
Okay. My concern was that not all common programming languages support negative enums, but from a quick google I could be wrong on this point. 

> 
> 6. Section 6 (Security):
> 
> Is there a risk that the capabilities information, if available offline
> and
> also from a device, could be used to fingerprint the device and gain
> information about what version of software/hardware is being run?
> BALAZS: I t could be used as part of the fingerprinting, as any readable
> data that changes infrequently. IMHO this is a generic problem, to be
> solved
> by proper access control rules. Adding it as a kind of standard boiler
> text
> to every YANG module would not help. Maybe we would need an OAM security
> RFC.
> 
[RW] 
Actually, perhaps this should just be in the security section of the instance data draft.  That would then seem to apply generally to all YANG modules used as instance data.

> 
> 7. Could you please add a brief section to thank folks who have
> contributed
> and reviewed this work.
> - I think that it easier to get reviews, if the time/effort spent in the
> review is acknowledged.
> BALAZS: I usually do it. It seems I forgot it now.
> 
> 
> 8. Appendix A:
> - Your examples look like they probably have some introduced line wrapping
> (e.g. for the description, node-selector, and others).  Perhaps we should
> be
> using the artwork draft for this, or alternatively add a comment that
> linespaces have been introduced in various fields to improve readability.
> BALAZS: I would prefer to wait till  draft-ietf-netmod-artwork-folding
> becomes a full RFC. Even creating/using the folding header without the RFC
> number is problematic.
[RW] 
I don't think that this should really be a problem.

draft-ietf-netmod-artwork-folding is int the RFC editor queue and has no missing references, i.e. it is going to become an RFC before this draft does, and the RFC editor will be able fix up the folding header.

Thanks,
Rob