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

From: Kent Watsen <[email-masked]>
Date: Wed, 4 Mar 2020 21:54:12 +0000

Dear All,

This WGLC has received zero responses, which is insufficient to progress the document at this time.  The chairs have therefore decided to extend the WGLC for another two weeks, now ending March 18th.  

Again, positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcomed.  This is useful and important, even from authors.  Objections, concerns, and suggestions are also welcomed at this time.

The NETCONF Chairs

> On Feb 17, 2020, at 8:27 PM, Kent Watsen <[email-masked]> wrote:
> 
> FWIW, this is WGLC #2, after the major updates resulting from WGLC #1 (in October).
> 
> K.
> 
> 
>> On Feb 17, 2020, at 7:47 PM, Kent Watsen <[email-masked]> wrote:
>> 
>> This message begins a two-week WGLC for draft-ietf-netconf-notification-capabilities-11 ending on March 2nd (a week before the IETF 107 submission cutoff deadline).  Here is a direct link to the HTML version of the draft:
>> 
>> 	https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-11
>> 
>> Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors.  Objections, concerns, and suggestions are also welcomed at this time.
>> 
>> Thank you,
>> NETCONF Chairs
>> _______________________________________________
>> netconf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Mar 2020 13:47:06 +0000

I have read the new version, and like the updated notification-support.  I
believe it ready for publication.

Eric

> Dear All,
> 
> This WGLC has received zero responses, which is insufficient to progress
the
> document at this time.  The chairs have therefore decided to extend the
> WGLC for another two weeks, now ending March 18th.
> 
> Again, positive comments, e.g., "I've reviewed this document and believe
it is
> ready for publication", are welcomed.  This is useful and important, even
> from authors.  Objections, concerns, and suggestions are also welcomed at
> this time.
> 
> The NETCONF Chairs
> 
> 
> 
> 
> > FWIW, this is WGLC #2, after the major updates resulting from WGLC #1
(in
> October).
> >> This message begins a two-week WGLC for
draft-ietf-netconf-notification-
> capabilities-11 ending on March 2nd (a week before the IETF 107 submission
> cutoff deadline).  Here is a direct link to the HTML version of the draft:
> >>
> >> Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!  This is useful and important, even
> from authors.  Objections, concerns, and suggestions are also welcomed at
> this time.
> >>
> >> Thank you,
> >> NETCONF Chairs

---

From: "taoran (F)" <[email-masked]>
Date: Fri, 6 Mar 2020 08:27:28 +0000

Hi, all,

I have two comments on this draft as follows:

1. Section 5.1 said:
“
   augment /sysc:system-capabilities/sysc:datastore-capabilities/ +
     |                                 sysc:per-node-capabilities:
     +--ro subscription-capabilities
        +--ro (update-period)?
        |  +--:(minimum-update-period)
        |  |  +--ro minimum-update-period?        uint32
        |  +--:(supported-update-period)
        |     +--ro supported-update-period*      uint32
        +--ro max-nodes-per-update?               uint32
        +--ro minimum-dampening-period?           uint32 {yp:on-change}?
        +--ro on-change-supported?                notification-support
        |                                                {yp:on-change}?
        +--ro periodic-notifications-supported?   notification-support
        +--ro supported-excluded-change-type*     union {yp:on-change}?
”
I believe on-change-supported and supported-excluded-change-type are related to each other, i.e., only when on-change-supported holds,
Support-excluded-change-type needs to be supported. Would it make sense to add when statement under supported-excluded-change-type.
One Follow up comment is should supported-excluded-change-type be applicable to config true node or config false node?

2. Section 5.2 said:
“
       leaf-list supported-excluded-change-type {
         if-feature yp:on-change;
         type union {
           type enumeration {
             enum none {
               value -2 ;
               description "None of the change types can be excluded.";
             }
             enum all {
               value -1 ;
               description
                 "Any combination of change types can be excluded.";
             }
           }
           type yp:change-type;
         }
         description "The change types that can be excluded in
           YANG-Push subscriptions.";
       }
”
It is not clear to me when should assign negative number to enum value, does it indicate it is an error or warning? If it is not, I prefer to assign positive numer to enum value.

Best regards,

Ran
-----邮件原件-----
发件人: netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2020年3月5日 5:54
收件人: [email-masked]
主题: Re: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-11

Dear All,

The NETCONF Chairs

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 6 Mar 2020 16:25:34 +0000

-----Original Message-----
From: netconf <[email-masked]> On Behalf Of taoran (F)
Sent: 2020. március 6., péntek 9:27
To: Kent Watsen <[email-masked]>; [email-masked]
Subject: [netconf] 答复: WGLC: draft-ietf-netconf-notification-capabilities-11

Hi, all,

1. Section 5.1 said:
“
I believe on-change-supported and supported-excluded-change-type are related to each other, i.e., only when on-change-supported holds, Support-excluded-change-type needs to be supported. Would it make sense to add when statement under supported-excluded-change-type.

BALAZS: OK, I will do it in the after the WGLC.

2. Section 5.2 said:
“
It is not clear to me when should assign negative number to enum value, does it indicate it is an error or warning? If it is not, I prefer to assign positive number to enum value.

BALAZS: The value statement allows the range -2147483648 to 2147483647. 
I chose negative numbers because yp:change-type is itself an enum 
with autonumbering.  Autonumbering will start from 0 and go up.
 So a negative number will never clash with it, a small positive number could.

Ran

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 6 Mar 2020 17:05:59 +0000

Hello,
Thinking a bit more about this I think we should not include the when statement because:
- It is possible that supported-excluded-change-type  is declared on the system level while on-change-supported is declared on datastore level. In such cases when the explicit declaration of on-change-supported and supported-excluded-change-type is done on different levels (system/datastore/specific data node) only a very complicated when statement would work.
- As this is output from the node, when statement are not even checked by many implementations
So while the idea is relevant, practically it would be too difficult.
Regards Balazs

-----Original Message-----
From: netconf <[email-masked]> On Behalf Of taoran (F)
Sent: 2020. március 6., péntek 9:27
To: Kent Watsen <[email-masked]>; [email-masked]
Subject: [netconf] 答复: WGLC: draft-ietf-netconf-notification-capabilities-11

1. Section 5.1 said:
“

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 9 Mar 2020 18:33:36 +0000

Hi,

Thank you for this work.  I've reviewed this document as an individual contributor and also as an early incoming AD review.

Overall comments:

I support the progression of this work, I think that it is both useful and important, and the document is well written.  I like the split into two separate YANG modules covering system capabilities vs YANG push notifications.  I think that in an ideal world this work would probably be split into two separate documents, one covering system capabilities, and the second for notification capabilities.  In particular, I could imagine the system capabilities evolving over time.  However, I also understand the desire to complete this work, and I don't want to delay it.

Comments on individual sections:

1. Title:
 Perhaps it would be more accurate to name it as 
   "YANG Modules for describing System Capabilities and Yang-Push Notification Capabilities?"
 
2. Abstract
I propose that you rework the text to.
 
 OLD:
 
    This document proposes two YANG modules.  The module ietf-system-
   capabilities provides a structure that can be used to specify any
   YANG related system capability.

   The module ietf-notification-capabilities allows a publisher to
   specify capabilities related to "Subscription to YANG Datastores"
   (YANG-Push).  It proposes to use YANG Instance Data to document this
   information and make it already available at implementation-time, but
   also allow it to be reported at run-time.
   
 NEW:
 
   This document defines two YANG modules:
   
   The module ietf-system-capabilities provides a structure that can be
   used to specify YANG related system capabilities for servers.  The module
   can be used in conjunction with YANG Instance Data to make this information
   available at implementation-time.  The module can also be used to report
   capability information from the server at run-time.

   The module ietf-notification-capabilities augments ietf-system-capabilities
   to specify capabilities related to "Subscription to YANG Datastores"
   (YANG-Push). 

3. Terminology:

- Please add a reference to "instance data" from draft-lengyel-netmod-yang-instance-data

- Add the sentence: "In addition, this document defines the following terms:"

- Perhaps change "On-change Notification Capability" -> "On-change notification capability"?
- Move the definition of on-change notification capability last.

- Implementation-time information and Run-time information.  I think that these definitions should only be defined in terms of "server" and not "publisher", because I think that these considerations apply to all system capabilities, not only notifications.  Perhaps also reference YANG instance data.

E.g.

OLD:

   Implementation-time information: Information about the publisher's or
   server's behavior that is made available during the implementation of
   the publisher/server, available from a source other then a running
   server.

   Run-time information: Information about the publisher's or server's
   behavior that is available from the running server via management
   protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].

NEW:

   Implementation-time information: Information about the server's
   behavior that is made available during the implementation of
   the server, available from a source other then a running server, such
   as YANG Instance Data [XXXX].

   Run-time information: Information about the server's behavior that is
   available from the running server via management protocols such as
   NETCONF [RFC6241] or RESTCONF [RFC8040].

4. Section 2:
Please state that the YANG modules are compliant to NMDA.

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.

- 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 ;-)

- For both "minimum-dampening-period" and on-change-supported", can probably remove "data store or" from the description.

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

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?

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.

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.

- Perhaps:

OLD:

 The following example is instance-data describing the notification
   capabilities of a hypothetical "acme-switch" ...
   
NEW:

 The following instance-data example describes the notification
   capabilities of a hypothetical "acme-switch" ...

- First example:
  "        </datastore-capabilities>" should be outdented at two spaces after first block.

- I would normally expect candidate/running to be listed before operational, although there is obviously no harm in having it the other way.

9. Appendix B:
 - Please add a note to ask the RFC Editor to remove this section on publication.
 
Nits:
 - Please check for full stops (e.g. terminology)

Thanks,
Rob

> From: netconf <[email-masked]> On Behalf Of Kent Watsen
> Sent: 04 March 2020 21:54
> To: [email-masked]
> Subject: Re: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-
> 11
> 
> Dear All,
> 
> the document at this time.  The chairs have therefore decided to extend
> the WGLC for another two weeks, now ending March 18th.
> 
> it is ready for publication", are welcomed.  This is useful and important,
> even from authors.  Objections, concerns, and suggestions are also
> welcomed at this time.
> 
> The NETCONF Chairs
> 
> 
> 
> 
> (in October).
> >> This message begins a two-week WGLC for draft-ietf-netconf-
> notification-capabilities-11 ending on March 2nd (a week before the IETF
> 107 submission cutoff deadline).  Here is a direct link to the HTML
> version of the draft:
> >>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 9 Mar 2020 20:47:25 -0700

I support the publication of this draft, but would like some of the issues addressed in the document. They are mostly nits that I am hoping can be addressed before sending it to IESG. I reviewed the -12 version of the document.

s 2 Introduction

s/as it part of/as it is part of/
s/Examples include:/Examples include/
s/even to individual/even individual/
s/both in implementation-time/both at implementation-time/

s 2.1 YANG-push Notification Capabilities

OLD:
      to check that capability information provided early, already in
      implementation-time is indeed what the publisher implements (is
      the supplied documentation correct?)

NEW:
      to check that capability information provided earlier, at
      implementation-time is what the publisher has implemented

s 3 Providing System Capability Information

s/already in implementation-time/already at implementation-time/

s 4.2 YANG Module & s 5.2 YANG Module

This section needs to list every draft/RFC referenced in the YANG model.

All imports should carry a reference statement to the draft/RFC they are importing from, e.g. ietf-netconf-acm.

s 7.2 The YANG Module Names Registry

The indentation of the second registry is off.

Finally, have all the examples in the appendix been validated?

Thanks.

> On Mar 4, 2020, at 1:54 PM, Kent Watsen <[email-masked]> wrote:
> 
> Dear All,
>

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 10 Mar 2020 09:06:29 +0000

From: netconf <[email-masked]> On Behalf Of Mahesh Jethanandani
Sent: 2020. március 10., kedd 4:47
To: Kent Watsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-11

I support the publication of this draft, but would like some of the issues
addressed in the document. They are mostly nits that I am hoping can be
addressed before sending it to IESG. I reviewed the -12 version of the
document.

s 2 Introduction

BALAZS: OK, updated in -13

OLD:

NEW:

BALAZS: OK, updated in -13

BALAZS: OK, updated in -13

BALAZS: Which model is missing from 4.2 or 5.2 ? I assume we don’t have to
reference our won RFC.

All imports should carry a reference statement to the draft/RFC they are
importing from, e.g. ietf-netconf-acm.

BALAZS: OK, updated in -13. 

BALAZS: OK, updated in -13

BALAZS: Yes, they have been loaded into a live Confd server.

Thanks.

On Mar 4, 2020, at 1:54 PM, Kent Watsen <[email-masked]
<mailto:[email-masked]> > wrote:

Dear All,

This WGLC has received zero responses, which is insufficient to progress the
document at this time.  The chairs have therefore decided to extend the WGLC
for another two weeks, now ending March 18th.  

Again, positive comments, e.g., "I've reviewed this document and believe it
is ready for publication", are welcomed.  This is useful and important, even
from authors.  Objections, concerns, and suggestions are also welcomed at
this time.

The NETCONF Chairs

On Feb 17, 2020, at 8:27 PM, Kent Watsen <[email-masked]
<mailto:[email-masked]> > wrote:

FWIW, this is WGLC #2, after the major updates resulting from WGLC #1 (in
October).

K.

On Feb 17, 2020, at 7:47 PM, Kent Watsen <[email-masked]
<mailto:[email-masked]> > wrote:

This message begins a two-week WGLC for
draft-ietf-netconf-notification-capabilities-11 ending on March 2nd (a week
before the IETF 107 submission cutoff deadline).  Here is a direct link to
the HTML version of the draft:

Thank you,
NETCONF Chairs
_______________________________________________
netconf mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
netconf mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
netconf mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netconf

---

From: Benoit Claise <[email-masked]>
Date: Tue, 10 Mar 2020 10:25:16 +0100

Hi Balázs,

The way I understand Mahesh's email, those two points below are the same 
issue, solved by:

       import ietf-netconf-acm {
         prefix nacm;

         reference

           "RFC 8341: Network Configuration Access”;   <— You are missing this.
       }
       import ietf-yang-library {
         prefix yanglib;
         description
           "Revision 2019-01-04 or a
            revision derived from it is REQUIRED.”;

                                                       <— And here

Regards, Benoit
> BALAZS: Which model is missing from 4.2 or 5.2 ? I assume we don’t 
> have to reference our won RFC.
>
> All imports should carry a reference statement to the draft/RFC they 
> are importing from, e.g. ietf-netconf-acm.
>

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 10 Mar 2020 12:24:08 +0000

-----Original Message-----
From: Rob Wilton (rwilton) <[email-masked]> 
Sent: 2020. március 9., hétfő 19:34
To: [email-masked]; Balázs Lengyel <[email-masked]>;
[email-masked]
Cc: Kent Watsen <[email-masked]>
Subject: RE: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-11

Hi,

Thank you for this work.  I've reviewed this document as an individual
contributor and also as an early incoming AD review.

Overall comments:

I support the progression of this work, I think that it is both useful and
important, and the document is well written.  I like the split into two
separate YANG modules covering system capabilities vs YANG push
notifications.  I think that in an ideal world this work would probably be
split into two separate documents, one covering system capabilities, and the
second for notification capabilities.  In particular, I could imagine the
system capabilities evolving over time.  However, I also understand the
desire to complete this work, and I don't want to delay it.

1. Title:
 Perhaps it would be more accurate to name it as 
   "YANG Modules for describing System Capabilities and Yang-Push
Notification Capabilities?"
BALAZS: OK
 
2. Abstract
 
 OLD:

   
 NEW:

   can be used in conjunction with YANG Instance Data to make this
information

   The module ietf-notification-capabilities augments
ietf-system-capabilities
   to specify capabilities related to "Subscription to YANG Datastores"
   (YANG-Push). 
BALAZS: OK

3. Terminology:

- Please add a reference to "instance data" from
draft-lengyel-netmod-yang-instance-data
BALAZS: OK

- Add the sentence: "In addition, this document defines the following
terms:"
BALAZS: OK

- Perhaps change "On-change Notification Capability" -> "On-change
notification capability"?
- Move the definition of on-change notification capability last.
BALAZS: OK

- Implementation-time information and Run-time information.  I think that
these definitions should only be defined in terms of "server" and not
"publisher", because I think that these considerations apply to all system
capabilities, not only notifications.  Perhaps also reference YANG instance
data.
BALAZS: I like the original text more, but I will change it. The term server
is included in both definitions. It can be debated whether sending
notifications is a server activity, as it not immediately connected to a
request; hence I originally  had the "publisher" included too.

E.g.

OLD:

NEW:

   
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.

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.

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. 

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.

- Perhaps:

OLD:

NEW:

BALAZS: OK

- First example:
  "        </datastore-capabilities>" should be outdented at two spaces
after first block.
BALAZS: OK

- I would normally expect candidate/running to be listed before operational,
although there is obviously no harm in having it the other way.

9. Appendix B:
 - Please add a note to ask the RFC Editor to remove this section on
publication.
BALAZS: OK
 
Nits:
 - Please check for full stops (e.g. terminology)
BALAZS: OK, I corrected what I found. If you see more, please notify me.

Thanks,
Rob

> Subject: Re: [netconf] WGLC: 
> draft-ietf-netconf-notification-capabilities-
> 11
> 
> Dear All,
> 
> This WGLC has received zero responses, which is insufficient to 
> progress the document at this time.  The chairs have therefore decided 
> to extend the WGLC for another two weeks, now ending March 18th.
> 
> Again, positive comments, e.g., "I've reviewed this document and 
> believe it is ready for publication", are welcomed.  This is useful 
> and important, even from authors.  Objections, concerns, and 
> suggestions are also welcomed at this time.
> 
> The NETCONF Chairs
> 
> 
> 
> 
> ready for publication", are welcome!  This is useful and important,

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 12 Mar 2020 10:46:17 +0000

Hi Balazs,

Please see inline.

> From: Balázs Lengyel <[email-masked]>
> Sent: 10 March 2020 12:24
> To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]; draft-
> [email-masked]
<snipped>
> 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".

> negative numbers is a way to avoid clashing with these implicitly assigned
[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. 

> to every YANG module would not help. Maybe we would need an OAM security
[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.

> becomes a full RFC. Even creating/using the folding header without the RFC
[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

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 12 Mar 2020 16:22:03 +0000

See BALAZS2 below.

-----Original Message-----
From: Rob Wilton (rwilton) <[email-masked]> 
Sent: 2020. március 12., csütörtök 11:46

> 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".
BALAZS2: I still think the "conform to the architecture" is very vague.
That modules are not called "foo-state" is trivial and can be seen from the
module names.
IMHO if we want such a standard text we should define what it means. It
would fit into a mail and later into the YANG guidelines.
Based on your insistence, for now I propose to add the sentence
" The module can be used both by NMDA and non-NMDA compliant systems."
Are you OK with my sentence ?
Note: as many of today's systems are not NMDA compliant it is equally or
more important to note that the model works with non-NMDA.
Actually I am not 100% sure what "works with non-NMDA" means either: E.g. it
does not hide important information that would only be visible in
operational datastore. 

>BALAZS2: Based on the opinions of Eric, Benoit and myself I will update
following alternative a). Added to description
      leaf minimum-dampening-period {
        description
           If this value is present and greater than zero, 
           that implies dampening is mandatory.";
> to every YANG module would not help. Maybe we would need an OAM security
[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.
BALAZS2:  IMHO fingerprinting is possible the same way on a live server, it
is not specific to instance data files. Fingerprinting is actually a much
bigger problem on a live server, as there are a lot of standard models
available (yanglib, netconf-monitoring, nacm, etc.) while in instance data
you only have a small set of specific modules (maybe just one). Instance
data is usually only a partial set, which might also hide specifics,
hindering fingerprinting. You many not even be sure which server the
instance data came from: There is no origin parameter in the header part. So
IMHO finger-printing is a FAR bigger problem  on a live server.

Also: This is the second security related issue that effects the whole
YANG/Netconf/Restconf ecosystem, so IMHO it should be dealt with in a
centralized manner, not by each YAM individually.
- fingerprinting
- updates to security mechanisms like the TLS algorithms for factory-reset

I would like to avoid the topic in my draft.
[RW] 

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.
BALAZS2: OK

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 12 Mar 2020 16:53:30 +0000

> Sent: 12 March 2020 16:22
[RW] 
I think that most recent standards just use this:

   The YANG data model in this document conforms to the Network
   Management Datastore Architecture (NMDA) defined in RFC 8342.

Often it goes in the abstract, but I think that putting it in the Introduction should be fine.

>            that implies dampening is mandatory.";
[RW] 
Okay, thanks for clarifying.

> - updates to security mechanisms like the TLS algorithms for factory-reset
[RW] 
Yes, okay for this draft.

Thanks,
Rob

> > (e.g. for the description, node-selector, and others).  Perhaps we
> should
> > be

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 12 Mar 2020 14:28:12 -0700

[Adding yang-doctors]

Hi Balazs,

On Mar 10, 2020, at 2:06 AM, Balázs Lengyel <[email-masked]> wrote:

I bring this up because I ran into issues when validating the https-notif model using ietf-subscribed-notification module, something that you also import. Here is what I see when I try to use yanglint to validate your example. In this case, I named your example as examples-notification-capabilities-1.xml.

bash-3.2$ yanglint -s -i -t auto -p /Volumes/External/git/iana/yang-parameters/ [email-masked] [email-masked] examples-notification-capabilities-1.xml 
err : Invalid keyword "require-instance".
err : Module "ietf-subscribed-notifications" parsing failed.
err : Importing "ietf-subscribed-notifications" module into "ietf-yang-push" failed.
err : Module "ietf-yang-push" parsing failed.
err : Importing "ietf-yang-push" module into "ietf-notification-capabilities" failed.
err : Module "ietf-notification-capabilities" parsing failed.

At first I thought the issue was with yanglint, because just like you I used confd and it did not complain. But folks over at libyang tell me that this was discussed as part of their issue  #881 <https://github.com/CESNET/libyang/issues/881> and the conclusion was that you cannot put require-instance in a derived type based on this <https://tools.ietf.org/html/rfc7950#section-9.9.3> text.

Who is correct in their assertion, libyang or confd/RFC8639?

In case anyone is wondering which ietf-subsciribed-notifications module is being imported, here it is:

bash-3.2$ ls ../iana/yang-parameters/[email-masked] <mailto:iana/yang-parameters/[email-masked]>

Cheers.

BTW, even if I comment out the ‘require-instance’ statement, yanglint complains about other issues with ietf-subscribed-notifications, which I will bring up in a separate thread.

Mahesh Jethanandani
[email-masked]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 17 Mar 2020 19:04:21 +0000

Kent, I've gone through rev-12 and believe the document is ready to progress.

Balazs, one question on first bullet in section 3. It uses SHALL (not SHOULD), looks like this is on purpose? If yes, I'd rather see MUST but that's just personal preference. (with all the SHOULD in that section the SHALL can be misread as SHOULD).

Regards,
Reshad,

On 2020-03-04, 4:54 PM, "netconf on behalf of Kent Watsen" <[email-masked] on behalf of [email-masked]> wrote:

    Dear All,

    
    The NETCONF Chairs

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 23 Mar 2020 07:55:06 +0000

Thanks, for the suggestion. I will change to MUST.
Balazs

-----Original Message-----
From: Reshad Rahman (rrahman) <[email-masked]> 
Sent: 2020. március 17., kedd 20:04
To: Kent Watsen <[email-masked]>; [email-masked]; Balázs Lengyel <[email-masked]>
Subject: Re: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-11

Regards,
Reshad,

    Dear All,

    
    The NETCONF Chairs