Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt

[Qin Wu]

-邮件原件-
发件人: Martin Bjorklund [mailto:m...@tail-f.com] 
发送时间: 2019年11月6日 15:36
收件人: Qin Wu 
抄送: kent+i...@watsen.net; h...@shrubbery.net; netmod@ietf.org
主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt

Qin Wu  wrote:
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
> 发送时间: 2019年11月6日 3:27
> 收件人: john heasley 
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt
> 
> 
> 
> Yes, I'm suggesting that this "clearing" be a requirement, even if the 
> operator has the choice between clear "only the configuration" and 
> "everything."  "might" -> "MUST".
> 
> The fine line between too vague and too much detail must be found. >>>
> 
> In addition,the "factory-reset" RPC MUST restore storage to factory 
> condition, including remove log files, remove temporary files, remove 
> certificates, keys, etc zero passwords, 
> 
> The process (SHOULD|MUST) zero/pattern-write then remove sensitive 
> files such as the TLS keys, configuration stores, etc.
> 
> [Qin]: Okay, here is the my proposed change:
> OLD TEXT:
> “
> In addition, the "factory-reset" RPC might also be used to trigger 
> some other restoring and resetting tasks such as files cleanup, 
> restarting the node or some of the SW processes, or setting some 
> security data/passwords to the default value, removing logs, removing 
> any temporary data (from datastore or elsewhere) etc.  When and why 
> these tasks are triggered is not the scope of this document.
> ”
> NEW TEXT:
> “
> In addition, the "factory-reset" RPC MUST restore storage to factory 
> condition, including remove log files, remove temporary files (from datastore 
> or elsewhere).
> It MUST also remove security credentials and restoring default 
> security settings including remove certificates, keys, zero passwords, etc. 
> The process invoked by the "factory-reset"
> RPC SHOULD zero/pattern-write than remove sensitive files such as the 
> TLS keys, configuration stores, etc. The RPC MAY also be used to 
> trigger some other resetting tasks such as restarting the node or some 
> of the software processes, activating the factory-default config which in 
> turn enables zero touch provision (ZTP).
> ”
> If you have better text, feel free to share.

I think your previously proposed text that didn't mention ZTP was better.  
Also, "MAY also be used to" sounds like it is the client's decision, so I 
suggest changing the last sentence to:

  The RPC MAY also trigger some other resetting tasks such as
  restarting the node or some of the software processes.

[Qin]: Works for me, thanks.

/martin



> 
> The RPC MAY provide an option to limit the actions to factory reset of 
> the configuration.
> [Qin]: we have add  nacm:default-deny-all on RPC we proposed. Security 
> section will be enhanced Based on Andy’s comment in the separate email.
> 
> Strongly agree.
> 
> Kent // contributor
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt

[Martin Bjorklund]

Qin Wu  wrote:
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
> 发送时间: 2019年11月6日 3:27
> 收件人: john heasley 
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt
> 
> 
> 
> Yes, I'm suggesting that this "clearing" be a requirement, even if the
> operator has the choice between clear "only the configuration" and
> "everything."  "might" -> "MUST".
> 
> The fine line between too vague and too much detail must be found. >>>
> 
> In addition,the "factory-reset" RPC MUST
> restore storage to factory condition, including
> remove log files,
> remove temporary files,
> remove certificates, keys, etc
> zero passwords,
> 
> 
> The process (SHOULD|MUST) zero/pattern-write then remove sensitive files
> such as the TLS keys, configuration stores, etc.
> 
> [Qin]: Okay, here is the my proposed change:
> OLD TEXT:
> “
> In addition, the "factory-reset" RPC might also be used to trigger
> some other restoring and resetting tasks such as files cleanup,
> restarting the node or some of the SW processes, or setting some
> security data/passwords to the default value, removing logs, removing
> any temporary data (from datastore or elsewhere) etc.  When and why
> these tasks are triggered is not the scope of this document.
> ”
> NEW TEXT:
> “
> In addition, the "factory-reset" RPC MUST restore storage to factory 
> condition,
> including remove log files, remove temporary files (from datastore or 
> elsewhere).
> It MUST also remove security credentials and restoring default security 
> settings including
> remove certificates, keys, zero passwords, etc. The process invoked by the 
> "factory-reset"
> RPC SHOULD zero/pattern-write than remove sensitive files such as the TLS 
> keys, configuration
> stores, etc. The RPC MAY also be used to trigger some other resetting tasks 
> such as restarting
> the node or some of the software processes, activating the factory-default 
> config which in turn
> enables zero touch provision (ZTP).
> ”
> If you have better text, feel free to share.

I think your previously proposed text that didn't mention ZTP was
better.  Also, "MAY also be used to" sounds like it is the client's
decision, so I suggest changing the last sentence to:

  The RPC MAY also trigger some other resetting tasks such as
  restarting the node or some of the software processes.


/martin



> 
> The RPC MAY provide an option to limit the actions to factory reset of
> the configuration.
> [Qin]: we have add  nacm:default-deny-all on RPC we proposed. Security 
> section will be enhanced
> Based on Andy’s comment in the separate email.
> 
> Strongly agree.
> 
> Kent // contributor
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-wwx-netmod-event-yang-04.txt

[Qin Wu]

Hi, Igor

发件人: Igor Bryskin [mailto:i_brys...@yahoo.com]
发送时间: 2019年11月5日 22:02
收件人: netmod@ietf.org; draft-bryskin-netconf-automation-y...@ietf.org; Lou 
Berger ; Qin Wu 
抄送: draft-wwx-netmod-event-y...@ietf.org
主题: Re: I-D Action: draft-wwx-netmod-event-yang-04.txt

Hi Qin,

Good discussion. Please, see in-line.

Igor

On Tuesday, November 5, 2019, 3:09:53 AM EST, Qin Wu 
mailto:bill...@huawei.com>> wrote:



Hi, Igor:

发件人: Igor Bryskin [mailto:i_brys...@yahoo.com]
发送时间: 2019年11月5日 3:06
收件人: Qin Wu mailto:bill...@huawei.com>>; 
netmod@ietf.org; 
draft-bryskin-netconf-automation-y...@ietf.org;
 Lou Berger mailto:lber...@labn.net>>
抄送: 
draft-wwx-netmod-event-y...@ietf.org
主题: Re: I-D Action: draft-wwx-netmod-event-yang-04.txt



Hi Qin,



Thanks for the effort.



My general question is  what is the ultimate objective/ambition of this work? 
Is it



1. Modeling the imperative policy style network automation as stipulated by the 
SUPA framework

  or

2. Event scoping of PUSH machinery



If 2. is the case, it would certainly make sense and might prove useful for 
many use cases. However, in this case you have neither reason nor right to use 
well understood abbreviation ECA, nor to refer to the SUPA documents. Neither 
it would make any sense to merge our contributions IMHO



If 1. is the case, then

here is our comments/suggestions as to how the work should in our opinion 
evolve going forward:



[Qin]:Good question, I think we mostly focus on modelling imperative policy in 
which ECA is a typical example of ECA model. In addition, we see Event scoping 
of PUSH machinery is a special case of ECA without Action to be specified.
We clarified the relation with YANG Push, we think YAN PUSH model can be 
augmented with some grouping defined in ECA model. So ECA model doesn’t need to 
tie with YANG Push.


IB>> True, but if we model generic ECAs, things like  PUSH Event scoping, Smart 
Filters, etc. come naturally as trivial private cases. There is no need to 
focus on them.

 [Qin]: Exactly.

1.The Expression clause in an ECA could be very complex and hence requires a 
complex syntax to articulate. To address this in our contribution 
(https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-yang/) we 
proposed two methods:

a) When configuring Condition using XPath expression string. This allows 
expressing Conditions of arbitrary complexity, but does require servers to 
(sufficiently) support XPath language;

[Qin]:XPATH expression is supported in model proposed in draft-wwx, it is 
modelled as one of member of union, i.e., instance-identifier, in addition, we 
support model three other member types

Type yang:object-identifier;

Type yang:uuid;
Type string

IB>> Good. Please, note that we were told on many occasions that because of 
potentiality very complex syntax of the ECA Condition clause, the XPath 
expression string is realistically the only choice, all alternatives are 
introduced for model completeness more than anything else - too cumbersome to 
be useful.

[Qin]: Tend to agree, this is complexity we can consider to get rid of.

b) For the case of simpler servers we defined elementary logical primitives 
that could be used in building bottom up in hierarchical manner complex logical 
expressions



[Qin]: I believe you are talking about Condition Expression, which is 
corresponding to ietf-trigger.yang defined in draft-wwx-netmod-event-yang-04. 
We model them as three trigger conditions

1.   An existence test monitors and manages the absence, presence, and 
change of a data object

2.   A Boolean test compares the value of the monitored object with the 
reference value and takes action according to the comparison result.

3.   A Threshold trigger condition regularly compares compares the value of 
the monitored object with the threshold values.
In each trigger condition, we will break down them into policy variable and 
policy value based on RFC3460, policy variable is renamed as target, policy 
value is renamed as value in proposed ECA model

IB>> IMHO this is not  sufficient, not even close.

[Qin]: Actually it can be extended, the essence of trigger condition is 
 which is similar to  in 
draft-bryskin
would you like to provide an example which can not be expressed by these 
trigger conditions?
I am open to the better design choice.


I feel you change the meaning of policy variable, since in bryskin’s draft, 
policy variable is described as an output parameter of an RPC which is not 
consistent with the definition in RFC3460, in my opinion.

IB>> No, I have not. In our definition a PV is a variable where an ECA thread 
stores results of computations and output of algorithms/RPCs, so that the 
results could be used within a single thread or between multiple threads of the 
same or different ECAs, could provide input for automatic 

Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt

[Qin Wu]

发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
发送时间: 2019年11月6日 3:27
收件人: john heasley 
抄送: netmod@ietf.org
主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt



Yes, I'm suggesting that this "clearing" be a requirement, even if the
operator has the choice between clear "only the configuration" and
"everything."  "might" -> "MUST".

The fine line between too vague and too much detail must be found. >>>

In addition,the "factory-reset" RPC MUST
restore storage to factory condition, including
remove log files,
remove temporary files,
remove certificates, keys, etc
zero passwords,


The process (SHOULD|MUST) zero/pattern-write then remove sensitive files
such as the TLS keys, configuration stores, etc.

[Qin]: Okay, here is the my proposed change:
OLD TEXT:
“
In addition, the "factory-reset" RPC might also be used to trigger
some other restoring and resetting tasks such as files cleanup,
restarting the node or some of the SW processes, or setting some
security data/passwords to the default value, removing logs, removing
any temporary data (from datastore or elsewhere) etc.  When and why
these tasks are triggered is not the scope of this document.
”
NEW TEXT:
“
In addition, the "factory-reset" RPC MUST restore storage to factory condition,
including remove log files, remove temporary files (from datastore or 
elsewhere).
It MUST also remove security credentials and restoring default security 
settings including
remove certificates, keys, zero passwords, etc. The process invoked by the 
"factory-reset"
RPC SHOULD zero/pattern-write than remove sensitive files such as the TLS keys, 
configuration
stores, etc. The RPC MAY also be used to trigger some other resetting tasks 
such as restarting
the node or some of the software processes, activating the factory-default 
config which in turn
enables zero touch provision (ZTP).
”
If you have better text, feel free to share.

The RPC MAY provide an option to limit the actions to factory reset of
the configuration.
[Qin]: we have add  nacm:default-deny-all on RPC we proposed. Security section 
will be enhanced
Based on Andy’s comment in the separate email.

Strongly agree.

Kent // contributor

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

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Qin Wu]

-邮件原件-
发件人: Mahesh Jethanandani [mailto:mjethanand...@gmail.com] 
发送时间: 2019年11月6日 8:57
收件人: Qin Wu 
抄送: Robert Wilton ; Kent Watsen ; 
netmod@ietf.org
主题: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

Hi Qin,

> On Nov 5, 2019, at 4:35 PM, Qin Wu  wrote:
> 
> 2. Suggest to add a
>> paragraph in the section 5 to explain which common type or type in 
>> specific module is imported
> [RW]
> 
> Please can you clarify this comment, because I'm not sure what you are 
> requesting here.  I've left an open issue to track this:  
> https://github.com/netmod-wg/interface-extensions-yang/issues/21
> 
> [Qin]: See 1st paragraph, section 4 of RFC8344 as an example.

[mj] You mean to say that the draft should specify which RFCs the module 
imports typedefs from, and which RFCs it references in the model somewhere in 
the draft. For example, it imports ietf-yang-types and therefore should refer 
to RFC 6991 somewhere in the draft (but outside the model). Right?

[Qin]:That's correct.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Mahesh Jethanandani]

Hi Qin,

> On Nov 5, 2019, at 4:35 PM, Qin Wu  wrote:
> 
> 2. Suggest to add a
>> paragraph in the section 5 to explain which common type or type in 
>> specific module is imported
> [RW] 
> 
> Please can you clarify this comment, because I'm not sure what you are 
> requesting here.  I've left an open issue to track this:  
> https://github.com/netmod-wg/interface-extensions-yang/issues/21
> 
> [Qin]: See 1st paragraph, section 4 of RFC8344 as an example.

[mj] You mean to say that the draft should specify which RFCs the module 
imports typedefs from, and which RFCs it references in the model somewhere in 
the draft. For example, it imports ietf-yang-types and therefore should refer 
to RFC 6991 somewhere in the draft (but outside the model). Right?

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

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Qin Wu]

 2. Suggest to add a
> paragraph in the section 5 to explain which common type or type in 
> specific module is imported
[RW] 

Please can you clarify this comment, because I'm not sure what you are 
requesting here.  I've left an open issue to track this:  
https://github.com/netmod-wg/interface-extensions-yang/issues/21

[Qin]: See 1st paragraph, section 4 of RFC8344 as an example.

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

Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt

[Kent Watsen]

> Yes, I'm suggesting that this "clearing" be a requirement, even if the
> operator has the choice between clear "only the configuration" and
> "everything."  "might" -> "MUST".
> 
> The fine line between too vague and too much detail must be found. >>>
> 
> In addition,the "factory-reset" RPC MUST
> restore storage to factory condition, including
> remove log files,
> remove temporary files,
> remove certificates, keys, etc
> zero passwords,
> 
> 
> The process (SHOULD|MUST) zero/pattern-write then remove sensitive files
> such as the TLS keys, configuration stores, etc.
> 
> The RPC MAY provide an option to limit the actions to factory reset of
> the configuration.


Strongly agree.

Kent // contributor

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

Re: [netmod] [netconf] WG Last Call: draft-ietf-netmod-factory-default-05

[Kent Watsen]

- NETCONF
+ NETMOD


> On Nov 5, 2019, at 6:44 AM, Kent Watsen  wrote:
> 
> Hi Qin,
> 
>> [Qin]: The question is should rpc or factory default config or both enable 
>> ztp?
>> I think during initial zero-touch configure, it is factory default config to 
>> enable ztp.
>> In the middle of session, rpc can be used to trigger ztp process execution.
> 
> The factory-default config enables ZTP.  
> The RPC activates the factory-default config. 
> 
> K.  
> ___
> netconf mailing list
> netc...@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt

[john heasley]

Tue, Nov 05, 2019 at 07:47:12AM +, Schönwälder, Jürgen:
> Yes to your point.
> 
> But every time I read the phrase "setting some security data/passwords
> to the default value" I am feeling uneasy. The notion of 'default
> passwords' is scary and a knob to restore default passwords even more
> so. Perhaps the text should say instead 'removing security credentials
> and restoring default security settings'.

Yes, I'm suggesting that this "clearing" be a requirement, even if the
operator has the choice between clear "only the configuration" and
"everything."  "might" -> "MUST".

The fine line between too vague and too much detail must be found. >>>

In addition,the "factory-reset" RPC MUST
restore storage to factory condition, including
remove log files,
remove temporary files,
remove certificates, keys, etc
zero passwords,


The process (SHOULD|MUST) zero/pattern-write then remove sensitive files
such as the TLS keys, configuration stores, etc.

The RPC MAY provide an option to limit the actions to factory reset of
the configuration.

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

Re: [netmod] I-D Action: draft-ietf-netmod-nmda-diff-03.txt

[Alexander Clemm]

Hi Netmod,

we have just posted a new revision of the mentioned draft.  We did add a brief 
performance consideration section and a new parameter to control whether or not 
to include origin metadata when  is a comparison target.  We think 
that all open issues have been addressed and hope that the draft can go to WGLC 
shortly.

Kind regards
--- Alex

> -Original Message-
> From: netmod  On Behalf Of internet-
> dra...@ietf.org
> Sent: Monday, November 04, 2019 3:54 PM
> To: i-d-annou...@ietf.org
> Cc: netmod@ietf.org
> Subject: [netmod] I-D Action: draft-ietf-netmod-nmda-diff-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Network Modeling WG of the IETF.
> 
> Title   : Comparison of NMDA datastores
> Authors : Alexander Clemm
>   Yingzhen Qu
>   Jeff Tantsura
>   Andy Bierman
>   Filename: draft-ietf-netmod-nmda-diff-03.txt
>   Pages   : 17
>   Date: 2019-11-04
> 
> Abstract:
>This document defines an RPC operation to compare management
>datastores that comply with the NMDA architecture.
> 
> 
> The IETF datatracker status page for this draft is:
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-nmda-
> diff%2Fdata=02%7C01%7Caclemm%40futurewei.com%7C64e867439f90
> 46c07fe908d761826aab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> C637085085095272379sdata=ngUS4O5WHqyEemzCW14DgGuE0Oa%2F2
> 3DxRQIkSoNrMwc%3Dreserved=0
> 
> There are also htmlized versions available at:
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf
> .org%2Fhtml%2Fdraft-ietf-netmod-nmda-diff-
> 03data=02%7C01%7Caclemm%40futurewei.com%7C64e867439f9046c0
> 7fe908d761826aab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637
> 085085095272379sdata=uHvCIm73KB5gUr%2BO5jhxZcNLOtuvTuvukDd
> mxLv2PWc%3Dreserved=0
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-nmda-diff-
> 03data=02%7C01%7Caclemm%40futurewei.com%7C64e867439f9046c0
> 7fe908d761826aab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637
> 085085095282372sdata=1ClGo1IuU8181s5nuvsVwW8xG38ODWK%2FdW
> O18UR0qI4%3Dreserved=0
> 
> A diff from the previous version is available at:
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Frfcdiff%3Furl2%3Ddraft-ietf-netmod-nmda-diff-
> 03data=02%7C01%7Caclemm%40futurewei.com%7C64e867439f9046c0
> 7fe908d761826aab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637
> 085085095282372sdata=R%2F7aCNmcsvPbz2200l6BjpfG31opd7WFUjAvij
> Twsl4%3Dreserved=0
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fnetmoddata=02%7C01%7Caclemm%40fu
> turewei.com%7C64e867439f9046c07fe908d761826aab%7C0fee8ff2a3b240189
> c753a1d5591fedc%7C1%7C0%7C637085085095282372sdata=YxyI19%2F
> 3G0QiR8GlgXsgbDl2kW8mgZKsATFcOYO2Pe0%3Dreserved=0

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

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Rob Wilton (rwilton)]

Hi Vladamir,

> -Original Message-
> From: netmod  On Behalf Of Rob Wilton (rwilton)
> Sent: 29 August 2019 17:20
> To: Vladimir Vassilev ; netmod@ietf.org
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> 
> Hi Vladimir,
> 
> Please see inline ...
> 
> > -Original Message-
> > From: Vladimir Vassilev 
> > Sent: 27 August 2019 15:55
> > To: Rob Wilton (rwilton) ; netmod@ietf.org
> > Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> >
> > On 22/08/2019 12.13, Rob Wilton (rwilton) wrote:
> >
> > > Hi Vladimir,
> > >
> > > Thanks for your detailed review.  Sorry for the slow reply, I've
> > > been
> > away.  I'm also about to be away again for a couple of days.
> > >
> > > Please see my comments inline ...
> > >
> > > I'll also track these issues to closure on
> > > https://github.com/netmod-wg/interface-extensions-yang/issues
> > >
> > >> -Original Message-
> > >> From: netmod  On Behalf Of Vladimir
> > >> Vassilev
> > >> Sent: 13 August 2019 17:05
> > >> To: Kent Watsen ; netmod@ietf.org
> > >> Subject: Re: [netmod] WG Last Call:
> > >> draft-ietf-netmod-intf-ext-yang-07
> > >>
> > >> I have reviewed the draft. I have the following (19) IMO useful
> > proposals:
> > >>
> > >> 1. Dedicated module (ietf-if-oper-status-debounce.yang) for the
> > >> oper- status debouncing/dampening functionality currently in
> > >> ietf-interfaces- common.yang.
> > > I don't think that we want a proliferation of too many separate YANG
> > modules for small features.  Each of the areas of different
> > functionality within this module are already conditional on
> > if-feature, so I don't think that there is a strong justification to
> > separating this out as a separate module.
> >
> > I still think that especially the "dampening" mechanism is not common
> > enough and is quite complex to be added to ietf-interfaces-common. If
> > a feature is not common or does not enable the use of generic modeling
> > mechanism (like sub-interfaces etc.) it should not be in
> > ietf-interfaces- common. I do not think "dampening" (maybe at some
> > point we should go back to damping instead e.g. rfc2439 ... seems
> > there is difference between dampening and damping and damping seems to
> > be the correct one) is that common to deserve a place in ietf-
> interfaces-common.
> [RW]
> 
> I've renamed the module to ietf-if-extensions.yang.
> 
> I still don't see that splitting this to a separate YANG module is
> helpful.
> 
[RW] 
I've now closed this issue (with the module renaming).

> 
> >
> > >
> > >> 2. In sec "3.1 Carrier delay" use of the under-defined "Carrier"
> > >> definition can be replaced with direct reference to the oper-status
> > >> leaf (which is what is actually targeted by the algorithm)
> > >> "Operational status transition debouncing".
> > > I think that different vendors have different names for this
> technology.
> > I've just used the one that our products use.  I think that this is
> > just a name, rather than something that has to be defined.  I could
> > add a comment that this feature is sometimes called hold time?
> >
> > I looked for precedents -  "carrier-delay" leaf Cisco, "debouncing-
> > interval" leaf Juniper, "interface-phys-holdtime-config"
> > leaf OpenConfig.
> >
> > I think "Carrier" is confusing since what is delayed actually is the
> > transition of the oper-status.
> [RW]
> 
> But it is not just the oper-status that is delayed (which would only
> affect manageability).
> 
> Instead, it is the internal notification to the higher layer protocols
> that the underlying interface link state has changed.  E.g. with carrier-
> delay down, the IP layer may still think that the interface is up when the
> Ethernet layer signalling indicates that the interface is actually down.
> 
> I'll have a think and see if I can come up with a clearer name for this.
[RW] 

Possibly, this could be renamed to something like "link-flap-suppression" or 
"state-flap-suppression"?

I've included this as one of the open issues, and will track on a separate 
thread.  


> 
> 
> >
> > >> 3. "timer-running" and "suppressed" leafs are both "config false"
> > >> and have "default" statements. Although this is valid YANG I do not
> > >> think the "default" statements are intended.
> > > I think that this is a more general question that needs a bit more
> > discussion.  Here, I am using defaults for the config false node to
> > document what the normal value is expected.
> > Well not a real issue but I thought it was an unusual use of default.
> 
[RW] 

I've removed the default values because they could potentially confusion if no 
value is returned (although RFC 8342 section 5.3 indicates the expected 
semantics in this case).




> 
> 
> > >
> > >
> > >> 4. Dedicated module (ietf-if-loopback.yang) for the loopback
> > >> functionality currently in ietf-interfaces-common.yang.
> > > Same answer as for 1. I don't think that we should have too many
> > > really
> > 

[netmod] WG LC for draft-ietf-netmod-intf-ext-yang

[Rob Wilton (rwilton)]

Hi,

draft-ietf-netmod-intf-ext-yang-08.txt should fix most of the issues raised 
during the WG LC.  Please can you check the diff 
(https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/history/) to 
ensure that your comments have been correctly addressed, closed issues are 
tracked at 
https://github.com/netmod-wg/interface-extensions-yang/issues?q=is%3Aissue+is%3Aclosed
 .



There are still some open issues, at 
https://github.com/netmod-wg/interface-extensions-yang/issues that need to be 
resolved, with proposed resolutions below:


1. Do we rename "Carrier-delay".

Possibly, this could be renamed to something like "link-flap-suppression" or 
"state-flap-suppression"?



2. Do we add in-pkts and out-pkts counters?
Effectively, these counters would be equivalent to the sum of the 
in-unicast-pkts + in-broadcast-pkts + in-multicast-pkts.

In hindsight, I wish the counters had been defined as:
in-pkts, in-broadcast-pkts, in-multicast-pkts.  I.e. where the broadcast and 
multicast counters are a subset of in-pkts.  This approach works for interfaces 
that don't distinguish between the types.

However, I'm not sure whether adding these counters into interface extensions 
is the right place.  If we were to add these counters, I think that it would be 
better to add them to a new revision of ietf-interfaces.yang.


3. Do we add a new "in-discards-overflow" counter?

I propose that we add this counter, with the following definition:

   leaf in-discards-overflow {
 type yang:counter32;
 description
   "The number of inbound packets that could have been
deliverable to a high-layer protocol but have been
discarded due to lack of resources to process the
packet.

This counter does not change the meaning of the
'in-discards' counter, and hence discarded packets
Counted against this counter MUST also be
counted in the 'in-discards' counter.

This counter does not include packets that are
discarded due to exceeding a QoS policy, only those
dropped due to resource constraints.

Discontinuities in the values of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of the 'discontinuity-time'
leaf defined in the ietf-interfaces YANG module (RFC 8343).";

 reference
   "RFC 2863: The Interfaces Group MIB - ifInDiscards";
   }

If we add this counter for ingress, then I suggest that we also define a 
similar counter for egress as well.


4. As discussed at IETF 105, I propose adding the following discard counter, 
unless there are strong objections:

  /*
   * Add discard counter for unknown sub-interface encapsulation
   */
  augment "/if:interfaces/if:interface/if:statistics" {
when "derived-from-or-self(../if:type,
   'ianaift:ethernetCsmacd') or
  derived-from-or-self(../if:type,
   'ianaift:ieee8023adLag') or
  derived-from-or-self(../if:type, 'ianaift:ifPwType')" {
  description
"Applies to interfaces that can demux to sub-interfaces";
}
if-feature "sub-interfaces";

description
  "Augment the interface model statistics with a sub-interface
   demux discard counter.";

leaf in-discard-unknown-encaps {
  type yang:counter64;
  units frames;
  description
"A count of the number of frames that were well formed, but
 otherwise discarded because their encapsulation does not
 classify to the interface or any child sub-interface.  E.g.,
 a packet might be discarded because the it has an unknown
 VLAN Id, or does not have a VLAN Id when one is expected.

 For consistency, frames counted against this counter are also
 counted against the IETF interfaces statistics.  In
 particular, they are included in in-octets and in-discards,
 but are not included in in-unicast-pkts, in-multicast-pkts or
 in-broadcast-pkts, because they are not delivered to a higher
 layer.

 Discontinuities in the values of this counter can occur at
 re-initialization of the management system, and at other
 times as indicated by the value of the 'discontinuity-time'
 leaf defined in the ietf-interfaces YANG module (RFC 8343).";
}
  }


5. l2-mtu leaf

I've changed the name and definition from "l2-mtu" to "max-frame-size".

I've changed the definition to be more encaps agnostic, so it included FCS 
bytes, and doesn't have any special IEEE 802.3 VLAN definition, and increased 
its size to uint32 to accommodate the Linux loopback MTU of 65536 bytes.

The propose new text is:

2.5.  Maximum frame size

   A maximum frame size configuration leaf 

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Rob Wilton (rwilton)]

Hi Qin,

Thank you for the review comments.

Apologies for the late reply on action on the WG LC comments.

Please see inline ...

> -Original Message-
> From: netmod  On Behalf Of Qin Wu
> Sent: 19 August 2019 10:23
> To: Kent Watsen ; netmod@ietf.org
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> 
> I have reviewed this document and have a few comments as follows:
> 1. Suggest to add references for imported module
[RW] 

I presume that you mean:

  import ietf-interfaces {
prefix if;
reference
  "RFC 8343: A YANG Data Model For Interface Management";
  }

If so, this is now done.


 2. Suggest to add a
> paragraph in the section 5 to explain which common type or type in
> specific module is imported
[RW] 

Please can you clarify this comment, because I'm not sure what you are 
requesting here.  I've left an open issue to track this:  
https://github.com/netmod-wg/interface-extensions-yang/issues/21


 3. s/ reference "Internet draft: draft-ietf-
> netmod-intf-ext-yang-07";/ reference "RFC: Common Interface Extension
> YANG Data Models";
[RW] 

I've changed the references to:

  revision 2019-11-04 {
description
  "Initial revision.";

reference
  "RFC , Common Interface Extension YANG Data Models";
  }

And

  feature carrier-delay {
description
  "This feature indicates that configurable interface
   carrier delay is supported, which is a feature is used to
   limit the propagation of very short interface link state
   flaps.";
reference "RFC , Section 2.1 Carrier Delay";
  }


 4. I am not sure L2 MTU is common attribute applicable
> to all packet frame based interface, in most case, we are using L3 MTU.
> >From the definition of L2 MTU
> " A layer 2 MTU configuration leaf (l2-mtu) is provided to specify the
> maximum size of a layer 2 frame that may be transmitted or received on an
> interface. "
> I am wondering this L2 MTU is related to Maximum Receive Unit defined in
> RFC4638. If the answer is YES, I would suggest to rename it, but it is
> still not clear whether it should be An common attribute part of ietf-
> interfaces-common.
> If it is No, I am wondering why L2 MTU is not augmented from IP address
> management module which define common MTU attribute, also it is not clear
> to me if ietf-interfaces-common Is positioned as technology specific
> model? When we choose to use MTU defined in RFC8344 and when we should
> choose to use L2 MTU defined in draft-ietf-netmod-intf-ext-yang-07.
> I think L3 MTU is common and widely deployed and supported by most of
> implementations. But go to L2 MTU:
> "
> The payload MTU available to higher layer protocols is either derived from
> the layer 2 MTU, taking into account the size of the layer 2 header, or is
> further restricted by explicit layer
> 3 or protocol specific MTU configuration."; "
> You add a lot of flexibility or multiple options, therefore I think it is
> hard to implement it.
[RW] 
Some platforms define MTU in terms of L3, and derive the maximum L2 frame size 
from that value.
Other platforms define MTU in terms of L2 frame size, and derive the maximum L3 
packet size from that value.

It is also useful to be able to see (e.g. in operational state) the actual 
maximum L2 frame that may be sent/received on an interface.

Further, if a service is L2 based then describing the maximum L2 frame that can 
be forwarded is more meaningful that describing the L3 payload of the data that 
may be carried, particularly if the size of the L2 header may not be of fixed 
size (e.g. depending on how many VLAN tags are configured).

I've changed the name and definition of L2 MTU to:

/*
 * Allows the maximum frame size to be configured or reported.
 */
leaf max-frame-size {
  if-feature "max-frame-size";
  type uint32 {
range "64 .. max";
  }
  description
"The maximum size of layer 2 frames that may be transmitted
 or received on the interface (including any frame header,
 maximum frame payload size, and frame checksum sequence).

 If configured, the max-frame-size also limits the maximum
 frame size of any child sub-interfaces.  The MTU available
 to higher layer protocols is restricted to the maximum frame
 payload size, and MAY be further restricted by explicit
 layer 3 or protocol specific MTU configuration.";
  
  reference "RFC , Section 2.5 Maximum Frame Size";
}

But I'll start a separate thread to close on the l2-mtu/max-frame-size issue 
(and the others).

Thanks,
Rob



> 
> -Qin
> -Original Message-
> From: netmod  On Behalf Of Kent Watsen
> Sent: 2019. július 10., szerda 2:15
> To: netmod@ietf.org
> Subject: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> 
> All,
> 
> This starts a twelve-day working group last call for
> draft-ietf-netmod-intf-ext-yang-07
> 
> The working group last call ends on July 21 

Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

[Rob Wilton (rwilton)]

Hi Acee,

No, not yet.  But I have added an issue to track this, so this doesn’t get 
forgotten.

I think that probably all of the published IEEE standard YANG modules should be 
added to the search path.

Thanks,
Rob


From: Acee Lindem (acee) 
Sent: 05 November 2019 12:01
To: Rob Wilton (rwilton) ; Stephen Cheng 
; netmod@ietf.org
Subject: Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

Hi Rob,

Any update on getting the YANG tools issue resolved with the 
ieee802-dot1q-types.yang model in the search path?

Thanks,
Acee

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of "Rob Wilton (rwilton)" mailto:rwil...@cisco.com>>
Date: Tuesday, November 5, 2019 at 4:50 AM
To: Stephen Cheng 
mailto:stephen.ch...@aviatnet.com>>, 
"netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

Hi Stephen,

I’ve just posted an updated version of this document.

The document is in WGLC, and I’m hoping that I can address any outstanding 
comments (including yours) over the next couple of weeks.

Kind regards,
Rob


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Stephen Cheng
Sent: 05 November 2019 02:30
To: netmod@ietf.org
Subject: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model


Authors  of draft-ietf-netmod-sub-intf-vlan-model,

I noticed that the draft has expired, is there any intention to publish a new 
version in new future?

Secondly, I notice a possible problem in the examples in section 7.1/7.2.

In current (expired) draft, in section 7.1. we have in the example

   
 eth0.1
 ianaift:l2vlan
 eth0
 
   
 
   dot1q-types:s-vlan
   10
 

The type of of eth0.1 interface is defined as a l2vlan.

L2vlan is defined in RFC 7224 as follows, which means that l2vlan does not 
derive from ethernetCsmacd nor ieee8023adLag nor ethSubInterface:

identity l2vlan {

   base iana-interface-type;

   description

 "Layer 2 Virtual LAN using 802.1Q.";

 }


However in the current (expired) draft, 
ietf-if-l3-v...@2019-03-05.yang says

 /*

  * Add support for the 802.1Q VLAN encapsulation syntax on layer 3

  * terminated VLAN sub-interfaces.

  */

 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +

 "if-cmn:encaps-type" {

   when

   "derived-from-or-self(../if:type,

 'ianaift:ethernetCsmacd') or

derived-from-or-self(../if:type,

 'ianaift:ieee8023adLag') or

derived-from-or-self(../if:type,

 'if-cmn:ethSubInterface')" {

 description

   "Applies only to Ethernet-like interfaces and

sub-interfaces";

   }



   description

 "Augment the generic interface encapsulation with an

  basic 802.1Q VLAN encapsulation for sub-interfaces.";



   /*

* Matches a single VLAN Id, or a pair of VLAN Ids to classify

* traffic into an L3 service.

*/

   case dot1q-vlan {

 container dot1q-vlan {

   must

 'count(../../if-cmn:forwarding-mode) = 0 or ' +

 'derived-from-or-self(../../if-cmn:forwarding-mode,' +

   '"if-cmn:layer-3-forwarding")' {

   error-message

 "If the interface forwarding-mode leaf is set then it

  must be set to an identity that derives from

  layer-3-forwarding";



   description

 "The forwarding-mode leaf on an interface can

  optionally be used to enforce consistency of

  configuration";

 }





   description

 "Match VLAN tagged frames with specific VLAN Ids";

   container outer-tag {

 must

   'tag-type = "dot1q-types:s-vlan" or ' +

   'tag-type = "dot1q-types:c-vlan"' {



   error-message

   "Only C-VLAN and S-VLAN tags can be matched";



   description

   "For IEEE 802.1Q interoperability, only C-VLAN and

S-VLAN tags can be matched";

 }



 description

   "Classifies traffic using the outermost VLAN tag on the

frame.";



 uses dot1q-types:dot1q-tag-classifier-grouping;

   }


As such if the type of eth 0.1 is l2vlan should outer-tag etc be available to 
this interface, since l2vlan would not satisfy the “when” clause?

I believe there are similar issues for other interfaces too in section 7.1/7.2 
examples.

Warm regards,
Stephen Cheng

___
netmod mailing list
netmod@ietf.org

Re: [netmod] I-D Action: draft-wwx-netmod-event-yang-04.txt

[Igor Bryskin]

 Hi Qin,

Good discussion. Please, see in-line.

Igor
On Tuesday, November 5, 2019, 3:09:53 AM EST, Qin Wu  
wrote:  
 
 
Hi, Igor:
 
发件人: Igor Bryskin [mailto:i_brys...@yahoo.com]
发送时间: 2019年11月5日 3:06
收件人: Qin Wu ; netmod@ietf.org; 
draft-bryskin-netconf-automation-y...@ietf.org; Lou Berger 
抄送: draft-wwx-netmod-event-y...@ietf.org
主题: Re: I-D Action: draft-wwx-netmod-event-yang-04.txt
 
  
 
Hi Qin,
 
  
 
Thanks for the effort.
 
  
 
My general question is  what is the ultimate objective/ambition of this work? 
Is it
 
  
 
1. Modeling the imperative policy style network automation as stipulated by the 
SUPA framework
 
  or
 
2. Event scoping of PUSH machinery
 
  
 
If 2. is the case, it would certainly make sense and might prove useful for 
many use cases. However, in this case you have neither reason nor right to use 
well understood abbreviation ECA, nor to refer to the SUPA documents. Neither 
it would make any sense to merge our contributions IMHO
 
  
 
If 1. is the case, then
 
here is our comments/suggestions as to how the work should in our opinion 
evolve going forward:
 
  
 
[Qin]:Good question, I think we mostly focus on modelling imperative policy in 
which ECA is a typical example of ECA model. In addition, we see Event scoping 
of PUSH machinery is a special case of ECA without Action to be specified.
 We clarified the relation with YANG Push, we think YAN PUSH model can be 
augmented with some grouping defined in ECA model. So ECA model doesn’t need to 
tie with YANG Push.


IB>> True, but if we model generic ECAs, things like  PUSH Event scoping, Smart 
Filters, etc. come naturally as trivial private cases. There is no need to 
focus on them.
 
  
 
1.The Expression clause in an ECA could be very complex and hence requires a 
complex syntax to articulate. To address this in our contribution 
(https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-yang/) we 
proposed two methods:
 
a) When configuring Condition using XPath expression string. This allows 
expressing Conditions of arbitrary complexity, but does require servers to 
(sufficiently) support XPath language;
 
[Qin]:XPATH expression is supported in model proposed in draft-wwx, it is 
modelled as one of member of union, i.e., instance-identifier, in addition, we 
support model three other member types
 Type yang:object-identifier; Type yang:uuid; Type string

IB>> Good. Please, note that we were told on many occasions that because of 
potentiality very complex syntax of the ECA Condition clause, the XPath 
expression string is realistically the only choice, all alternatives are 
introduced for model completeness more than anything else - too cumbersome to 
be useful.
 
b) For the case of simpler servers we defined elementary logical primitives 
that could be used in building bottom up in hierarchical manner complex logical 
expressions
 
  
 
[Qin]: I believe you are talking about Condition Expression, which is 
corresponding to ietf-trigger.yang defined in draft-wwx-netmod-event-yang-04. 
We model them as three trigger conditions
 
1.  An existence test monitors and manages the absence, presence, and 
change of a data object
 
2.  A Boolean test compares the value of the monitored object with the 
reference value and takes action according to the comparison result.
 
3.  A Threshold trigger condition regularly compares compares the value of 
the monitored object with the threshold values.
 In each trigger condition, we will break down them into policy variable and 
policy value based on RFC3460, policy variable is renamed as target, policy 
value is renamed as value in proposed ECA model

IB>> IMHO this is not  sufficient, not even close.
 I feel you change the meaning of policy variable, since in bryskin’s draft, 
policy variable is described as an output parameter of an RPC which is not 
consistent with the definition in RFC3460, in my opinion.

IB>> No, I have not. In our definition a PV is a variable where an ECA thread 
stores results of computations and output of algorithms/RPCs, so that the 
results could be used within a single thread or between multiple threads of the 
same or different ECAs, could provide input for automatic re-configurations and 
RPCs, could be used in Condition evaluations, could be exposed directly to the 
client via notifications, etc. In short, this is the place where ECAs store and 
accumulate the results of their work 
  
 
2. Your model seems to suggest for ECA Action  not much more than PUSHing a 
notification (triggered by a certain event and satisfying the configured 
condition) to the client with the hope that the client will subsequently 
request some device/network re-configurations ro react to the event.
 
  
 
[Qin]:Igor, the ECA action proposed in the model of 
draft-wwx-netmod-event-yang-04 can do more than PUSHing a notification, it have 
supported the following capabilities:
 1)Configuration data object reconfiguration

IB>> Good, but keep in 

Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

[Acee Lindem (acee)]

Hi Rob,

Any update on getting the YANG tools issue resolved with the 
ieee802-dot1q-types.yang model in the search path?

Thanks,
Acee

From: netmod  on behalf of "Rob Wilton (rwilton)" 

Date: Tuesday, November 5, 2019 at 4:50 AM
To: Stephen Cheng , "netmod@ietf.org" 

Subject: Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

Hi Stephen,

I’ve just posted an updated version of this document.

The document is in WGLC, and I’m hoping that I can address any outstanding 
comments (including yours) over the next couple of weeks.

Kind regards,
Rob


From: netmod  On Behalf Of Stephen Cheng
Sent: 05 November 2019 02:30
To: netmod@ietf.org
Subject: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model


Authors  of draft-ietf-netmod-sub-intf-vlan-model,

I noticed that the draft has expired, is there any intention to publish a new 
version in new future?

Secondly, I notice a possible problem in the examples in section 7.1/7.2.

In current (expired) draft, in section 7.1. we have in the example

   
 eth0.1
 ianaift:l2vlan
 eth0
 
   
 
   dot1q-types:s-vlan
   10
 

The type of of eth0.1 interface is defined as a l2vlan.

L2vlan is defined in RFC 7224 as follows, which means that l2vlan does not 
derive from ethernetCsmacd nor ieee8023adLag nor ethSubInterface:

identity l2vlan {

   base iana-interface-type;

   description

 "Layer 2 Virtual LAN using 802.1Q.";

 }


However in the current (expired) draft, 
ietf-if-l3-v...@2019-03-05.yang says

 /*

  * Add support for the 802.1Q VLAN encapsulation syntax on layer 3

  * terminated VLAN sub-interfaces.

  */

 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +

 "if-cmn:encaps-type" {

   when

   "derived-from-or-self(../if:type,

 'ianaift:ethernetCsmacd') or

derived-from-or-self(../if:type,

 'ianaift:ieee8023adLag') or

derived-from-or-self(../if:type,

 'if-cmn:ethSubInterface')" {

 description

   "Applies only to Ethernet-like interfaces and

sub-interfaces";

   }



   description

 "Augment the generic interface encapsulation with an

  basic 802.1Q VLAN encapsulation for sub-interfaces.";



   /*

* Matches a single VLAN Id, or a pair of VLAN Ids to classify

* traffic into an L3 service.

*/

   case dot1q-vlan {

 container dot1q-vlan {

   must

 'count(../../if-cmn:forwarding-mode) = 0 or ' +

 'derived-from-or-self(../../if-cmn:forwarding-mode,' +

   '"if-cmn:layer-3-forwarding")' {

   error-message

 "If the interface forwarding-mode leaf is set then it

  must be set to an identity that derives from

  layer-3-forwarding";



   description

 "The forwarding-mode leaf on an interface can

  optionally be used to enforce consistency of

  configuration";

 }





   description

 "Match VLAN tagged frames with specific VLAN Ids";

   container outer-tag {

 must

   'tag-type = "dot1q-types:s-vlan" or ' +

   'tag-type = "dot1q-types:c-vlan"' {



   error-message

   "Only C-VLAN and S-VLAN tags can be matched";



   description

   "For IEEE 802.1Q interoperability, only C-VLAN and

S-VLAN tags can be matched";

 }



 description

   "Classifies traffic using the outermost VLAN tag on the

frame.";



 uses dot1q-types:dot1q-tag-classifier-grouping;

   }


As such if the type of eth 0.1 is l2vlan should outer-tag etc be available to 
this interface, since l2vlan would not satisfy the “when” clause?

I believe there are similar issues for other interfaces too in section 7.1/7.2 
examples.

Warm regards,
Stephen Cheng

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

Re: [netmod] Default choice case with only empty leaf - Is this allowed ?

[Martin Bjorklund]

Hi,

"Beauville, Yves (Nokia - BE/Antwerp)"  wrote:
> Hello,
> 
> In the example provided in section 7.9.3 of RFC7950, is it legal to 
> redefine the default case like below?
> 
>   container transfer {
>     choice how {
>   default manual; // redefined
>   case interval {
>     leaf interval {
>   type uint16;
>   units minutes;
>   default 30;
>     }
>   }
>   case daily {
>     leaf daily {
>   type empty;
>     }
>     leaf time-of-day {
>   type string;
>   units 24-hour-clock;
>   default "01.00";
>     }
>   }
>   case manual {
>     leaf manual {
>   type empty;
>     }
>   }
>     }
>   }

Section 7.9.3 says:

   The default case is only important when considering the "default"
   statements of nodes under the cases (i.e., default values of leafs
   and leaf-lists, and default cases of nested choices).  The default
   values and nested default cases under the default case are used if
   none of the nodes under any of the cases are present.

So, yes it is legal, but doesn't mean anything.

> What is expected to happen when an  request creates the 
> 'transfer' container without providing any data for the choice 'how'?

The behaviour is the same as if you didn't have the default statement
in the choice.

> Since an empty leaf conveys information by its presence or absence, and 
> cannot have a default value, is it correct to assume that the 'manual' 
> leaf will be present, even though it was not explicitly created by the 
>  request?

No.

> Can someone clarify?



/martin

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

Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

[Rob Wilton (rwilton)]

Hi Stephen,

I've just posted an updated version of this document.

The document is in WGLC, and I'm hoping that I can address any outstanding 
comments (including yours) over the next couple of weeks.

Kind regards,
Rob


From: netmod  On Behalf Of Stephen Cheng
Sent: 05 November 2019 02:30
To: netmod@ietf.org
Subject: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model


Authors  of draft-ietf-netmod-sub-intf-vlan-model,

I noticed that the draft has expired, is there any intention to publish a new 
version in new future?

Secondly, I notice a possible problem in the examples in section 7.1/7.2.

In current (expired) draft, in section 7.1. we have in the example

   
 eth0.1
 ianaift:l2vlan
 eth0
 
   
 
   dot1q-types:s-vlan
   10
 

The type of of eth0.1 interface is defined as a l2vlan.

L2vlan is defined in RFC 7224 as follows, which means that l2vlan does not 
derive from ethernetCsmacd nor ieee8023adLag nor ethSubInterface:

identity l2vlan {

   base iana-interface-type;

   description

 "Layer 2 Virtual LAN using 802.1Q.";

 }


However in the current (expired) draft, 
ietf-if-l3-v...@2019-03-05.yang says

 /*

  * Add support for the 802.1Q VLAN encapsulation syntax on layer 3

  * terminated VLAN sub-interfaces.

  */

 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +

 "if-cmn:encaps-type" {

   when

   "derived-from-or-self(../if:type,

 'ianaift:ethernetCsmacd') or

derived-from-or-self(../if:type,

 'ianaift:ieee8023adLag') or

derived-from-or-self(../if:type,

 'if-cmn:ethSubInterface')" {

 description

   "Applies only to Ethernet-like interfaces and

sub-interfaces";

   }



   description

 "Augment the generic interface encapsulation with an

  basic 802.1Q VLAN encapsulation for sub-interfaces.";



   /*

* Matches a single VLAN Id, or a pair of VLAN Ids to classify

* traffic into an L3 service.

*/

   case dot1q-vlan {

 container dot1q-vlan {

   must

 'count(../../if-cmn:forwarding-mode) = 0 or ' +

 'derived-from-or-self(../../if-cmn:forwarding-mode,' +

   '"if-cmn:layer-3-forwarding")' {

   error-message

 "If the interface forwarding-mode leaf is set then it

  must be set to an identity that derives from

  layer-3-forwarding";



   description

 "The forwarding-mode leaf on an interface can

  optionally be used to enforce consistency of

  configuration";

 }





   description

 "Match VLAN tagged frames with specific VLAN Ids";

   container outer-tag {

 must

   'tag-type = "dot1q-types:s-vlan" or ' +

   'tag-type = "dot1q-types:c-vlan"' {



   error-message

   "Only C-VLAN and S-VLAN tags can be matched";



   description

   "For IEEE 802.1Q interoperability, only C-VLAN and

S-VLAN tags can be matched";

 }



 description

   "Classifies traffic using the outermost VLAN tag on the

frame.";



 uses dot1q-types:dot1q-tag-classifier-grouping;

   }


As such if the type of eth 0.1 is l2vlan should outer-tag etc be available to 
this interface, since l2vlan would not satisfy the "when" clause?

I believe there are similar issues for other interfaces too in section 7.1/7.2 
examples.

Warm regards,
Stephen Cheng

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

[netmod] Default choice case with only empty leaf - Is this allowed ?

[Beauville, Yves (Nokia - BE/Antwerp)]

Hello,

In the example provided in section 7.9.3 of RFC7950, is it legal to 
redefine the default case like below?

  container transfer {
    choice how {
  default manual; // redefined
  case interval {
    leaf interval {
  type uint16;
  units minutes;
  default 30;
    }
  }
  case daily {
    leaf daily {
  type empty;
    }
    leaf time-of-day {
  type string;
  units 24-hour-clock;
  default "01.00";
    }
  }
  case manual {
    leaf manual {
  type empty;
    }
  }
    }
  }

What is expected to happen when an  request creates the 
'transfer' container without providing any data for the choice 'how'?

Since an empty leaf conveys information by its presence or absence, and 
cannot have a default value, is it correct to assume that the 'manual' 
leaf will be present, even though it was not explicitly created by the 
 request?

Can someone clarify?


Yves

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

[netmod] Framework for Use of ECA (Event Condition Action) in Network Self Management

[Qin Wu]

Hi, All:
We have submitted a draft to discuss ECA Framework
https://tools.ietf.org/html/draft-bwd-netmod-eca-framework-00

Abstract:
"
Event-driven management is meant to provide a useful method to
monitor state change of managed objects and resources, and facilitate
automatic triggering of a response to events, based on an established
set of rules.  This would provide rapid autonomic responses to
specific conditions, enabling self-management behaviors, including:
self-configuration, self-healing, self-optimization, and self-
protection.

This document provides a framework that describes the architecture
for supporting event-driven management of managed object state across
devices.
"
Your comments/input/contribution are welcome.

-Qin (on behalf of authors)
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2019年11月4日 15:43
收件人: i-d-annou...@ietf.org
主题: I-D Action: draft-bwd-netmod-eca-framework-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Framework for Use of ECA (Event Condition Action) in 
Network Self Management
Authors : Mohamed Boucadair
  Qin Wu
  Michael Wang
  Daniel King
  Chongfeng Xie
Filename: draft-bwd-netmod-eca-framework-00.txt
Pages   : 15
Date: 2019-11-03

Abstract:
   Event-driven management is meant to provide a useful method to
   monitor state change of managed objects and resources, and facilitate
   automatic triggering of a response to events, based on an established
   set of rules.  This would provide rapid autonomic responses to
   specific conditions, enabling self-management behaviors, including:
   self-configuration, self-healing, self-optimization, and self-
   protection.

   This document provides a framework that describes the architecture
   for supporting event-driven management of managed object state across
   devices.  It does not describe specific protocols or protocol
   extensions needed to realize the objectives and capabilities
   discussed in the document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bwd-netmod-eca-framework/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-bwd-netmod-eca-framework-00
https://datatracker.ietf.org/doc/html/draft-bwd-netmod-eca-framework-00


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt

[Qin Wu]

Thanks Jurgen and John, the proposed change works for me.

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Sch?nw?lder, Jürgen
发送时间: 2019年11月5日 15:47
收件人: john heasley 
抄送: netmod@ietf.org
主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt

On Tue, Nov 05, 2019 at 07:42:06AM +, john heasley wrote:
>In addition,the "factory-reset" RPC might also be used
>to trigger some other restoring and resetting tasks such as files
>cleanup, restarting the node or some of the software processes,
>setting some security data/passwords to the default value, removing
>logs, or removing any temporary data (from datastore or elsewhere),
>etc.
> 
> It seems that this should all be part of this draft.  An operation 
> that wipes a device for decommission is useful.  Whether it is a home 
> or commercial device.

Yes to your point.

But every time I read the phrase "setting some security data/passwords to the 
default value" I am feeling uneasy. The notion of 'default passwords' is scary 
and a knob to restore default passwords even more so. Perhaps the text should 
say instead 'removing security credentials and restoring default security 
settings'.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] I-D Action: draft-wwx-netmod-event-yang-04.txt

[Qin Wu]

Hi, Igor:
发件人: Igor Bryskin [mailto:i_brys...@yahoo.com]
发送时间: 2019年11月5日 3:06
收件人: Qin Wu ; netmod@ietf.org; 
draft-bryskin-netconf-automation-y...@ietf.org; Lou Berger 
抄送: draft-wwx-netmod-event-y...@ietf.org
主题: Re: I-D Action: draft-wwx-netmod-event-yang-04.txt

Hi Qin,

Thanks for the effort.

My general question is  what is the ultimate objective/ambition of this work? 
Is it

1. Modeling the imperative policy style network automation as stipulated by the 
SUPA framework
  or
2. Event scoping of PUSH machinery

If 2. is the case, it would certainly make sense and might prove useful for 
many use cases. However, in this case you have neither reason nor right to use 
well understood abbreviation ECA, nor to refer to the SUPA documents. Neither 
it would make any sense to merge our contributions IMHO

If 1. is the case, then
here is our comments/suggestions as to how the work should in our opinion 
evolve going forward:

[Qin]:Good question, I think we mostly focus on modelling imperative policy in 
which ECA is a typical example of ECA model. In addition, we see Event scoping 
of PUSH machinery is a special case of ECA without Action to be specified.
We clarified the relation with YANG Push, we think YAN PUSH model can be 
augmented with some grouping defined in ECA model. So ECA model doesn’t need to 
tie with YANG Push.

1.The Expression clause in an ECA could be very complex and hence requires a 
complex syntax to articulate. To address this in our contribution 
(https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-yang/) we 
proposed two methods:
a) When configuring Condition using XPath expression string. This allows 
expressing Conditions of arbitrary complexity, but does require servers to 
(sufficiently) support XPath language;
[Qin]:XPATH expression is supported in model proposed in draft-wwx, it is 
modelled as one of member of union, i.e., instance-identifier, in addition, we 
support model three other member types

Type yang:object-identifier;

Type yang:uuid;
Type string
b) For the case of simpler servers we defined elementary logical primitives 
that could be used in building bottom up in hierarchical manner complex logical 
expressions

[Qin]: I believe you are talking about Condition Expression, which is 
corresponding to ietf-trigger.yang defined in draft-wwx-netmod-event-yang-04. 
We model them as three trigger conditions

1.   An existence test monitors and manages the absence, presence, and 
change of a data object

2.   A Boolean test compares the value of the monitored object with the 
reference value and takes action according to the comparison result.

3.   A Threshold trigger condition regularly compares compares the value of 
the monitored object with the threshold values.
In each trigger condition, we will break down them into policy variable and 
policy value based on RFC3460, policy variable is renamed as target, policy 
value is renamed as value in proposed ECA model

I feel you change the meaning of policy variable, since in bryskin’s draft, 
policy variable is described as an output parameter of an RPC which is not 
consistent with the definition in RFC3460, in my opinion.

2. Your model seems to suggest for ECA Action  not much more than PUSHing a 
notification (triggered by a certain event and satisfying the configured 
condition) to the client with the hope that the client will subsequently 
request some device/network re-configurations ro react to the event.

[Qin]:Igor, the ECA action proposed in the model of 
draft-wwx-netmod-event-yang-04 can do more than PUSHing a notification, it have 
supported the following capabilities:
1)Configuration data object reconfiguration
2) ECA Log report Notification

3)Invoke another Event
It can be extended to support more advanced features if needed.

There are situations, however, when the said re-configurations must be applied 
immediately after the event detection with no time to loose on network- client 
communications. Furthermore, there are cases when the necessary 
re-configurations are known a priory (at the time of the ECA configuration), 
and the client may want to pre-configure them along with configuring  the ECA's 
Event and Condition, and then rely on what we call close loop network 
automation, rather than to be involved in device/network micro management in 
real time. To this end our contribution suggests the flowing ECA Action 
configuration options:
a) Network re-configuration (in the form of per-configured Netconf edit config 
statements); [Qin]: We support this.
b) PUSHing notifications to the client (the same as you suggest) [Qin]: Correct.
c) Enabling/disabling notification streams (pre-configured as PUSH 
subscriptions); [Qin]: Do you propose to allow netconf server send notif to the 
client and instruct client to enable or disable notification stream or the 
network server can enable or disable some
event stream and inform the client the result?
d) Invoking local network