Re: [netmod] [Incoming] AD review of draft-ietf-netmod-factory-default-12

[Qin Wu]

Thanks Rob for good review and proposed text, I will incorporate them in v-13, 
the only comment I am not sure is comment 3, I have nothing to add for 
instruction for RFC editor besides
RFC Editor note in the YANG data model code to remind the RFC Editor to replace 
RFC xxx and related date to actual RFC number and publication date respectively.

-Qin
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2020年2月25日 0:05
收件人: draft-ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org
抄送: Warren Kumari 
主题: [Incoming] AD review of draft-ietf-netmod-factory-default-12

Hi,

Thanks for writing this document.  I found this document to be well written, 
clear and understandable.  However, there are a few issues which I think could 
be addressed before kicking off IETF LC.

I have the following comments:


  1.  Title: The title of the document may be clearer as: “A YANG Data Model 
for Factory Default Settings”.


  1.  Abstract: I would suggest condensing the abstract, which is currently 
very similar to the introduction, perhaps to the following text:



 “This document defines a YANG data model to allow clients to

  reset a server back to its factory default condition.  It

  also defines a “factory-default” datastore to allow clients

  to read the factory default configuration for the device.



  The YANG data model in this document conforms to the Network

  Management Datastore Architecture (NMDA) defined in RFC 
8342.
   ”


  1.  Introduction: It might be useful to include instructions for the RFC 
editor at the beginning of the introduction to summarize what actions are 
required before publication.



  1.  Terminology (section 1.1).   For the definition of the factory-default 
datastore, I would add the sentence “This datastore is referred to as 
".”



  1.  Terminology (section 1.1).  I propose that you also important the term 
“datastore schema” from RFC 8342, for use with a proposed update to section 3.



  1.  Section 2, third bullet.  It might be better to replace “ephemeral 
datastores” with “dynamic configuration datastores”, since that is the 
reference is RFC 8342.



  1.  Section 3, first paragraph.  I suggest removing the word minimal, i.e. 
“preconfigured minimal initial configuration” => “preconfigured initial 
configuration”, since it isn’t required that the factory default configuration 
is minimal, although it would normally be so.


  1.  Section 3. I think that the document must define what the schema is for 
the “factory-default”.  Hence, rather than “YANG modules: all”, perhaps “YANG 
modules: The factory default datastore schema MUST either be the same as the 
conventional configuration datastores, or a subset of the datastore schema for 
the conventional configuration datastores.”


  1.  Section 3. Probably add the following sentence to the end of section 3: 
“If supported, the factory-default datastore MUST be included in the list of 
datastores in YANG library [RFC 8525].”  This would probably also add RFC 8525 
as a normative reference.


  1.  YANG module, rpc factory-reset description.  I suggest changing the 
description to



“The server resets all datastores to their factory default content and any 
non-volatile storage back to factory condition, deleting all dynamically 
generated files, including those containing keys, certificates, logs, and other 
temporary files.



Depending on the factory default configuration, after being reset, the device 
may become unreachable on the network.”


  1.  I think that the security section needs to explicitly mention that non 
volatile storage is expected to be wiped clean and reset back to the factory 
default state, but that there is no guarantee that the data is wiped to any 
particular data cleansing particular standard, and the owner of the device MUST 
NOT rely on any temporary data (e.g., including private keys) being 
unrecoverable after the factory-reset RPC has been invoked.


Nits:

Section 2:
“are all reset to” => “are reset to”
“datastores(e.g. “ => “datastores (e.g., “

Section 3:
“with  => “with the ”.

Section 7: “, Susan Hares to review this draft and provide important input to 
this document” => “, and Susan Hares for reviewing this document and providing 
important input”.

Regards,
Rob

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on how to design a Yang model to reflect auto-asignment of a give leaf

[Sterne, Jason (Nokia - CA/Ottawa)]

Agree that ideally we avoid (a) in running. Unfortunately I think we used (a) 
in ietf-interfaces though:

 leaf type {
   type identityref {
 base interface-type;
   }
   mandatory true;
   description
 "The type of the interface.

  When an interface entry is created, a server MAY
  initialize the type leaf with a valid value, e.g., if it
  is possible to derive the type from the name of the
  interface.

I do like (c) but note that it means the value calculated by the server may not 
be persistent (e.g. across reboot). It depends how the server calculates the 
value. If it is "allocated" from some sort of free list, then at reboot it may 
select a different value than the previously selected value.

Jason

> -Original Message-
> From: netmod  On Behalf Of Martin Bjorklund
> Sent: Wednesday, February 12, 2020 2:48 AM
> To: Oscar González de Dios 
> Cc: ops...@ietf.org; netmod@ietf.org
> Subject: Re: [netmod] Question on how to design a Yang model to reflect auto-
> asignment of a give leaf
> 
> Oscar González de Dios  wrote:
> >
> >
> > -Mensaje original-
> > De: Martin Bjorklund 
> > Enviado el: martes, 11 de febrero de 2020 11:00
> > Para: Oscar González de Dios 
> > CC: ops...@ietf.org; netmod@ietf.org
> > Asunto: Re: [netmod] Question on how to design a Yang model to reflect
> > auto-asignment of a give leaf
> >
> > Hi,
> >
> > Oscar González de Dios  wrote:
> > > Dear OPSAWG and Netmod colleagues,
> > >
> > > During last IETF Opsawg meeting we raised a question (and
> > > there was some discussion during the meeting) that we have
> > > found yet no good answer and we would like to discuss it
> > > with
> > > operations and Yang experts.
> > >
> > > The use case is the following: We have a yang module which
> > > holds certain optional leafs. The behaviors that we would
> > > like
> > > to have (and distinguish between them) are:
> > >
> > >
> > > a) The user does not provide the value and such value is auto-assigned
> > > by the system (a device (if it is a device module) or a controller (if
> > > it is a network/service module)).
> >
> > I assume that this value not a static default value?
> >
> > [Oscar] True. Should the leaf have a default value, it implies that
> > "if the value is not set, the default value is taken".
> >
> > > b) The user does not provide a value and wants that such value IS NOT
> > > set by the system (as assigning a value has implications). That is,
> > > intentionally it is aimed at being left "empty" and should not be
> > > expanded. So, either the value is set or should remain empty
> >
> > Do you mean that you want (a) and (b) at the same time for the same
> > leaf?
> >
> > [Oscar] No. Depending on the leaf, we would like to specify behavior a
> > or behavior b. Behavior a is ok for most of the cases.  The problem is
> > that in some cases, assigning a value has way more implications and
> > the service will not work properly. Those case are the ones we wanted
> > to specifically tackle.
> 
> Ok.  See below.
> 
> > > What is the best way to model this behavior? I see that some yang
> > > modules have added an "auto-assignment" leaf to express if
> > > auto-assignment is desired or not. (hence, auto-assignment false, and
> > > leaf not set, would do not assign).
> > >
> > > Which is the "default" rule for a leaf that is not set? It is that the
> > > system is free to create it (via template or any means of
> > > auto-assignment) or should leave it as is, that is, empty?
> > >
> > > In NMDA, the system is allowed to expand a given configuration. This
> > > fact, in my personal view, implies that by "default" any system could
> > > implement the "auto-assignment" behavior being compliant with
> > > Neconf/Restconf/NMDA rules (but I am not sure if the interpretation is
> > > correct).
> >
> > There are (at least) three ways to interpret "auto-assign".  The
> > client writes to running, and then the server auto-assigns X:
> >
> >   (a) in running
> >   (b) in intended
> >   (c) in the operational state
> >
> > (c) is uncontroversial and simple to implement in all servers, and
> > simple to understand.
> > [Oscar] agree
> >
> > (b) is allowed by NMDA but requires more of the server implementation;
> > specifically it requires the server to support that intended is
> > different from running.
> > [Oscar] Agree . "Theoretically speaking" this is the behavior I would
> > consider strictly follows NMDA guidelines. Reality is implementations
> > are yet far from this...
> >
> > (a) is not recommended in general; running should be fully owned by
> > the client(s) and not modified by the server.
> > [Oscar] Agree.
> >
> > [Oscar] So... what would be the best way to specify the behavior?
> > Explicitly adding an 

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

[Xufeng Liu]

Agree with Dan. The use case is valid, though the errors in the data model
can be fixed.
Support.
Thanks,
- Xufeng

On Wed, Feb 19, 2020 at 6:44 AM King, Daniel  wrote:

> Hi All,
>
>
>
> Expressing, and delegating base imperative policy to network nodes
> (regardless if it’s a switch, router, network function, or indeed
> “controller”) is a critical step for facilitating network automation. I
> support the I-D and would like to see the WG adopt the work. Yes, the I-D
> needs to be developed further and this would be better managed if the
> effort was owned by the WG.
>
>
>
> I do agree somewhat with Jürgen that past experiences have shown a lack
> of willingness between vendors for expressing policy (imperative or
> otherwise). Major vendors have tended to implement their own policy
> language, or specific purpose (security, role management, et al.) language
> that has been based on standards (formal) or open-source project (de
> facto). The fact that the I-D author and contributor list already has a
> good mix of implementors demonstrates a willingness to develop an
> interoperable network-wide solution.
>
>
>
> BR, Dan.
>
>
>
> *From:* netmod  *On Behalf Of *Benoit Claise
> *Sent:* 19 February 2020 10:46
> *To:* Schönwälder, Jürgen ; Joel
> Jaeggli 
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang
>
>
>
> Jürgen,
>
> To tell that I was skeptical about the SUPA work is just wrong.
>
> I had great hopes for SUPA, as having consistent policy constructs in YANG
> module was key. The big hope was that those SUPA constructs could be
> re-used in other YANG modules
> example: routing, ACL, security ...
> Regardless of the location: in a network element or in a
> controller/orchestrator
> Regardless of the function: network element and service YANG modules
> If successful, in the end, SUPA would have helped to reuse code.
>
> Was I disappointed by the progress? Yes. The results were not there while
> the rest of the world uses their YANG policy constructs. Timing was key so,
> as AD, I had to pull the plug.
> The world has moved on. So be it.
> You can't infer skepticism from pragmatism.
>
> Now, back to the draft.
> From a network element point, I stressed the need to take have *simple *ECA
> rules directly routers.
> Think about RMON event/alarm but for YANG. Think about removing the RMON
> event/alarm restrictions that it works only for integer/counter.
> If your point is that the draft is not perfect, fair point.
> Should we solve attempt to solve that issue? Yes.
>
> A confusion comes from the abstract that implies that this work is based
> on SUPA.
>
> Abstract
>
>
>
>RFC8328 defines a policy-based management framework that allows
>
>definition of a data model to be used to represent high-level,
>
>possibly network-wide policies.  Policy discussed in RFC8328 are
>
>classified into imperative policy and declarative policy, Event
>
>Condition Action (ECA) policy is an typical example of imperative
>
>policy.  This document defines a YANG data model for the ECA policy
>
>management.  The ECA policy YANG provides the ability for the network
>
>management function (within a network element) to control the
>
>configuration and monitor state change and take simple and instant
>
>action on the server when a trigger condition on the system state is
>
>met.
>
> Actually, in my mind, the abstract should be simplified to something such
> as (and yes, it could be improved)
>
> Abstract
>
>
>
>This document defines a YANG data model for the ECA policy
>
>management.  The ECA policy YANG provides the ability for the network
>
>management function (within a network element) to control the
>
>configuration and monitor state change and take simple and instant
>
>action on the server when a trigger condition on the system state is
>
>met.
>
> And then, somewhere in the introduction, the following text should be
> reused:
>
>RFC8328 defines a policy-based management framework that allows
>
>definition of a data model to be used to represent high-level,
>
>possibly network-wide policies.  Policy discussed in RFC8328 are
>
>classified into imperative policy and declarative policy, Event
>
>Condition Action (ECA) policy is an typical example of imperative
>
>policy.
>
>
> Regards, Benoit.
>
> On Tue, Feb 18, 2020 at 08:44:18AM -0800, Joel Jaeggli wrote:
>
> This email begins a 2 week working group adoption poll for:
>
>
>
> https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06
>
>
>
> Please voice your support or objections before the poll completes on
>
> March 3rd.
>
>
>
> I am against adoption of this draft. I wonder whether Benoit will
>
> explain his contributions to this document; Benoit was added as a
>
> co-author in -06 and he used to be rather sceptical about the SUPA
>
> work (and this is essentially part of the SUPA work resubmitted to the
>
> NETMOD WG). 

[netmod] [Incoming] AD review of draft-ietf-netmod-factory-default-12

[Rob Wilton (rwilton)]

Hi,

Thanks for writing this document.  I found this document to be well written, 
clear and understandable.  However, there are a few issues which I think could 
be addressed before kicking off IETF LC.

I have the following comments:


  1.  Title: The title of the document may be clearer as: "A YANG Data Model 
for Factory Default Settings".


  1.  Abstract: I would suggest condensing the abstract, which is currently 
very similar to the introduction, perhaps to the following text:



 "This document defines a YANG data model to allow clients to

  reset a server back to its factory default condition.  It

  also defines a "factory-default" datastore to allow clients

  to read the factory default configuration for the device.



  The YANG data model in this document conforms to the Network

  Management Datastore Architecture (NMDA) defined in RFC 
8342.
   "


  1.  Introduction: It might be useful to include instructions for the RFC 
editor at the beginning of the introduction to summarize what actions are 
required before publication.



  1.  Terminology (section 1.1).   For the definition of the factory-default 
datastore, I would add the sentence "This datastore is referred to as 
"."



  1.  Terminology (section 1.1).  I propose that you also important the term 
"datastore schema" from RFC 8342, for use with a proposed update to section 3.



  1.  Section 2, third bullet.  It might be better to replace "ephemeral 
datastores" with "dynamic configuration datastores", since that is the 
reference is RFC 8342.



  1.  Section 3, first paragraph.  I suggest removing the word minimal, i.e.. 
"preconfigured minimal initial configuration" => "preconfigured initial 
configuration", since it isn't required that the factory default configuration 
is minimal, although it would normally be so.


  1.  Section 3. I think that the document must define what the schema is for 
the "factory-default".  Hence, rather than "YANG modules: all", perhaps "YANG 
modules: The factory default datastore schema MUST either be the same as the 
conventional configuration datastores, or a subset of the datastore schema for 
the conventional configuration datastores."


  1.  Section 3. Probably add the following sentence to the end of section 3: 
"If supported, the factory-default datastore MUST be included in the list of 
datastores in YANG library [RFC 8525]."  This would probably also add RFC 8525 
as a normative reference.


  1.  YANG module, rpc factory-reset description.  I suggest changing the 
description to



"The server resets all datastores to their factory default content and any 
non-volatile storage back to factory condition, deleting all dynamically 
generated files, including those containing keys, certificates, logs, and other 
temporary files.



Depending on the factory default configuration, after being reset, the device 
may become unreachable on the network."


  1.  I think that the security section needs to explicitly mention that non 
volatile storage is expected to be wiped clean and reset back to the factory 
default state, but that there is no guarantee that the data is wiped to any 
particular data cleansing particular standard, and the owner of the device MUST 
NOT rely on any temporary data (e.g., including private keys) being 
unrecoverable after the factory-reset RPC has been invoked.


Nits:

Section 2:
"are all reset to" => "are reset to"
"datastores(e.g. " => "datastores (e.g., "

Section 3:
"with  => "with the ".

Section 7: ", Susan Hares to review this draft and provide important input to 
this document" => ", and Susan Hares for reviewing this document and providing 
important input".

Regards,
Rob

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR poll on draft-wwx-netmod-event-yang

[Xufeng Liu]

No, I'm not aware of any IPR that applies to this draft.

Thanks,
- Xufeng

On Tue, Feb 18, 2020 at 11:45 AM Joel Jaeggli  wrote:

> Authors, Contributors, WG,
>
> As part of preparation for WG Adoption
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think
> appropriate.
>
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
> Thank you,
> NetMod WG Chairs
>
> PS Please include all listed in the headers of this message in your
> response.
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

[Qin Wu]

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Sch?nw?lder, Jürgen
发送时间: 2020年2月19日 20:18
收件人: Benoit Claise 
抄送: netmod@ietf.org
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Benoit,

thanks for the clarification.

I still believe that the approach taken is wrong. I doubt that network 
operators are interested in an assembly level approach for expressing threshold 
triggers. I am not sure xpath is the answer either. What was perhaps reasonable 
to try in the 90s (RMON, DISMAN work) may not be reasonably today anymore.

The example starting on page 43 seems to be doing this

  every 10 minutes
  ifexists(/ietf-interfaces:interfaces='eth0')
  and   if:interface[if:name='eth0']/if:statistic/if:in-errors >= 100
  then  /if:interfaces/if:interface[if:name='eth0']/if:enable = false

but it requires 1.5 pages of XML to express this (and then the rule is not even 
meaningful since comparing an absolute value of a counter is not useful).

If we are serious about policies, I believe we need to think about a 
language-based approach that can be read and understood and which does the 
things that are meaningful. Let me makeup some pseudo code based on the example 
that can work for all eth* interfaces and that gets the delta calculation of 
the counter right.

  if = /ietf-interfaces:interfaces/interface # json style namespace binding
  dt = 600 # 10 minutes in seconds
  every dt
  foreach name in $if/name:
this = $if/[name=$name]
if   $name matches 'eth.*'
and  delta($this/statistic/in-errors, dt) >= 100
then $this/enable = false

If people are serious about doing this kind of work, start by collecting 
real-world policies that need to be expressable, then identify the "language" 
mechanisms that are needed (loops over lists, bindings, variables and 
substitutions, pattern matching, ...) and then find a suitable representation. 
Yes, this is also something that people wanted SUPA to do and it did fail 
because it was already hard to collect real-world policies that help to 
understand what kind of mechanisms are needed and why.

[Qin]: This work has been for a while. The scope could be further narrow down. 
One of use cases we proponents all agrees is event based telemetry, the ECA 
configuration can be pushed down to the device, and then the script on the 
server can be automatically generated and manage the data object that is 
monitored on the device.
What ECA is doing is to find a suitable representation to express condition and 
logical and mathematical expressions
With XPATH expression language or extension, it is still difficult to come up 
with a suitable representation and trigger the action invoked on the device. 
But with ECA configuration populated on the device, the device can generate 
script based on network control logic described by ECA configuration. I am not 
sure there is better solution.
Also I believe what is not reasonable in the 90s for the legacy device may be 
ready for today now.
/js

On Wed, Feb 19, 2020 at 11:45:39AM +0100, Benoit Claise wrote:
> Jürgen,
> 
> To tell that I was skeptical about the SUPA work is just wrong.
> 
> I had great hopes for SUPA, as having consistent policy constructs in 
> YANG module was key. The big hope was that those SUPA constructs could 
> be re-used in other YANG modules
>     example: routing, ACL, security ...
>     Regardless of the location: in a network element or in a 
> controller/orchestrator
>     Regardless of the function: network element and service YANG 
> modules If successful, in the end, SUPA would have helped to reuse code.
> 
> Was I disappointed by the progress? Yes. The results were not there 
> while the rest of the world uses their YANG policy constructs. Timing 
> was key so, as AD, I had to pull the plug.
> The world has moved on. So be it.
> You can't infer skepticism from pragmatism.
> 
> Now, back to the draft.
> From a network element point, I stressed the need to take have _simple 
> _ECA rules directly routers.
> Think about RMON event/alarm but for YANG. Think about removing the 
> RMON event/alarm restrictions that it works only for integer/counter.
> If your point is that the draft is not perfect, fair point.
> Should we solve attempt to solve that issue? Yes.
> 
> A confusion comes from the abstract that implies that this work is 
> based on SUPA.
> 
> Abstract
> 
>RFC8328 defines a policy-based management framework that allows
>definition of a data model to be used to represent high-level,
>possibly network-wide policies.  Policy discussed in RFC8328 are
>classified into imperative policy and declarative policy, Event
>Condition Action (ECA) policy is an typical example of imperative
>policy.  This document defines a YANG data model for the ECA policy
>management.  The ECA policy YANG provides the ability for the network
>management function (within a network element) to control the
>configuration and monitor state change and take