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

[Igor Bryskin]

Hi Qin, 






Thanks for  the  interesting and fruitful discussion. 




The most important next step in my opinion is to agree on how we model PVs. 
Specifically, 


1. How the client can configure a PV  of a known type (defined in a YANG model 
supported  by the server); 


2. How the client can use PVs in the ECAs (computation actions, condition 
evaluation, RPC input/output, notifications sent to the client, etc.) 




This done, I believe, everything else will fall into place rather quickly and 
relatively simple. 


F2F meeting in Singapore will help a lot. 


Unfortunately,  I am not coming to Singapore,  but Xufeng will be there. I am 
looking forward  to a good progress. 




Cheers and good luck, 


Igor 






Get Outlook for Android







On Thu, Nov 7, 2019 at 8:07 AM -0500, "Qin Wu"  wrote:




















Hi, Igor:


Thank for your clarification, please see my follow up comments.


发件人: Igor Bryskin [mailto:i_brys...@yahoo.com]


发送时间: 2019年11月6日
 23:04

收件人: 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,



 



[ snipped]





.







 






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.



 



 




IB2>>> Realistically, this is not much of a use. Imagine you are a client and 
you have to express a condition made of some 80 logical operations.
 Using the above would be very cumbersome. And  what if in addition to the 
logical operations condition expression includes other operations, such as 
arithmetic, function calls, etc. ?




 






 [Qin-2]: I agree arithmetic, function calls is useful, but it is defined as 
part of action in the ECA model, right? Not
 part of condition statement?


Just to clarify, the target defined under event in draft-wwx is a target list, 
which is similar to policy variables list.
 Two key elements in trigger conditions are target, value, target is pointing 
to target under event and doesn’t need to be the data object that is being 
monitored or managed, it can be policy variable that is not presented in any 
YANG data model, value is expressed
 as one similar to  In draft-bryskin.
Operator in Boolean condition trigger case is similar to comparison-operation, 
it is not clear to me why condition made of 80 logical operations can not be 
described,
 maybe logical-operation-type should be introduced in the ECA model explicitly. 
We actually talk about this AND and OR design in the section 3.1 of 
draft-bwd-netmod-eca-framework-00.
In addition,
I am wondering how to describe a 

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

[Qin Wu]

Hi, Igor:
Thank for your clarification, please see my follow up comments.
发件人: Igor Bryskin [mailto:i_brys...@yahoo.com]
发送时间: 2019年11月6日 23:04
收件人: 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,

[ snipped]



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.


IB2>>> Realistically, this is not much of a use. Imagine you are a client and 
you have to express a condition made of some 80 logical operations. Using the 
above would be very cumbersome. And  what if in addition to the logical 
operations condition expression includes other operations, such as arithmetic, 
function calls, etc. ?


 [Qin-2]: I agree arithmetic, function calls is useful, but it is defined as 
part of action in the ECA model, right? Not part of condition statement?

Just to clarify, the target defined under event in draft-wwx is a target list, 
which is similar to policy variables list. Two key elements in trigger 
conditions are target, value, target is pointing to target under event and 
doesn’t need to be the data object that is being monitored or managed, it can 
be policy variable that is not presented in any YANG data model, value is 
expressed as one similar to  In draft-bryskin. Operator in Boolean 
condition trigger case is similar to comparison-operation, it is not clear to 
me why condition made of 80 logical operations can not be described, maybe 
logical-operation-type should be introduced in the ECA model explicitly. We 
actually talk about this AND and OR design in the section 3.1 of 
draft-bwd-netmod-eca-framework-00.

In addition,

I am wondering how to describe a condition when a network event is triggered 
when the monitored object disappear or appear or change
How do you describe a condition when network event is triggered if the 
difference between the current measurement value and the previous
measurement value of monitored data object is smaller than or equal to the 
delta falling threshold.
I see the big difference is you defined local policy variable, distinct from 
global policy variable, global policy variable can apply to multiple script. I 
am not sure these scripts are generated from ECA YANG data model? Or 
pre-configured? How these scripts are different func call or XPAH function?
In addition, it is not clear to me why we mixed policy variable with policy 
value. I can not see difference between them by reading draft-bryskin. The 
policy value can be constant, or change based on some calculation method, see 
example of condition in section 5.8.3 of rfc3460. Do we need to align with 
RFC3460?




I feel you 

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Nov 6, 2019 at 2:40 PM Balázs Lengyel 
> wrote:
> 
> > See below!Balazs
> >
> >
> >
> > *From:* netmod  *On Behalf Of *Andy Bierman
> > *Sent:* 2019. október 10., csütörtök 17:34
> > *To:* Martin Bjorklund 
> > *Cc:* NetMod WG 
> > *Subject:* Re: [netmod] comments on
> > draft-ietf-netmod-yang-instance-file-format-04
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund  wrote:

[...]

> >   o  Data node naming.
> >
> > The current structure of the model is:
> >
> > +--rw (content-schema-spec)?
> > |  +--:(simplified-inline)
> > | +--rw module* string
> > |  +--:(inline)
> > |  |  +--rw inline-spec*string
> > |  |  +--rw inline-content-schema   
> > |  +--:(uri)
> > | +--rw schema-uri?   inet:uri
> > ...
> > +--rw content-data? 
> >
> >
> > To make the instance document more understandable, I suggest the
> > following structure, which adds a wrapping container for the
> > schema, and renames the inline and uri nodes:
> >
> > +--rw content-schema
> >+--rw (content-schema-spec)?
> >|  +--:(simplified-inline)
> >| +--rw module* string
> >|  +--:(inline)
> >|  |  +--rw inline-module*  string
> >|  |  +--rw inline-schema   
> >|  +--:(uri)
> >| +--rw same-schema-as-file?inet:uri
> > ...
> > +--rw content-data? 
> >
> >
> >
> > +1, except not in favor of so many ways to specify schema.
> >
> > That means the file reader MUST support all of them.
> >
> >
> >
> > BALAZS: All 3 formats have been explicitly requested by earlier
> > commenters. I see a rational for each:
> >
> > Simplified-inline: it is simple and usually enough
> >
> > Inline: if you need to specify not just the modules but also the supported
> > features and deviations you need this full format
> >
> > Uri: if you don’t really want to specify the content-schema in detail,
> > e.g., because you are generating many files with the same schema, all you
> > need is reference that identifies the content-schema
> >
> >
> >
> > Which one would you like to implementing? Maybe we could make the inline
> > method optional with a feature (feature if-feature),
> >
> >
> >
> 
> I will just deviate out the stuff not worth implementing. ;-)
> I prefer the schema-uri approach but simplified-inline is probably easiest
> to implement.
> 
> The schema-uri looks standard but the contents of the referenced YANG
> instance file can be
> anything (as opposed to a pre-defined YANG template like /yang-library).

Note that the name of this leaf is misleading (see my ealrier
comments).  It is really 'same-schema-as-file', which means that it
point to another YANG instance data file, which must specify its
schema in one of the three ways.  Which may be another schema-uri, but
in the end the recursion must stop and you must find a YANG instance
data file that usses 'simplified-inline' or 'inline'.

> The inline-content-schema object looks broken because a YANG file is a text
> string.

It is supposed to be data nodes for /yang-library or perhaps
/module-sets, or perhaps something else.  See the examples in section
3.2.


/martin


> How does one use anydata to encode a text string? (It must be a container
> of YANG data nodes).
> Even the YIN representation is not a set of YANG data nodes, so anydata
> encoding seems wrong.
> Including all the YANG modules in this file seems especially heavyweight.
> (I have no intention of supporting this mode.)
> 
> 
> 
> > Andy
> >
> 
> 
> Andy
> 
> 
> > ___
> > 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] comments on draft-ietf-netmod-yang-instance-file-format-04

[Martin Bjorklund]

Balázs Lengyel  wrote:
> See below!Balazs
> 
>  
> 
> From: netmod  On Behalf Of Andy Bierman
> Sent: 2019. október 10., csütörtök 17:34
> To: Martin Bjorklund 
> Cc: NetMod WG 
> Subject: Re: [netmod] comments on 
> draft-ietf-netmod-yang-instance-file-format-04
> 
>  
> 
>  
> 
>  
> 
> On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund   > wrote:
> 
> 
>   o  leaf-list module
> 
> The type of this leaf-list is a string with:
> 
>   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
> 
> I think the revision needs to be optional, and the suffix ".yang"
> dropped, since it doesn't add any value:
> 
>   pattern '.+(@\d{4}-\d{2}-\d{2})?';
> 
>(same for inline-spec).
> 
>  
> 
> IMO the filespec SHOULD follow the pattern in  
> https://tools.ietf.org/html/rfc7950#section-5.2
> 
> BALAZS: It does follow the pattern except that I made the revision date 
> mandatory. It is needed to properly understand the instance data.
> 
>  
> 
> Except a new file extension SHOULD be used.
> 
> Suggest: .yif == YANG Instance File
> 
>  
> 
> Obviously it would be a horrible idea to use .yang since that extension
> 
> is already used to identify a YANG schema file.
> 
> BALAZS: The leaf-list lists not the instance data files but the content 
> defining YANG modules, so IMO “.yang” is an appropriate extension. It is 
> really a YANG schema file we are listing.

No, you are not listing a file name, you are listing the name and,
optionally, the revision of a YANG *module*.  It can internally be
stored as a .yang file a .yin file, or as a blob in a database.

Hence, we should not have the ".yang" suffix here.


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

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Martin Bjorklund]

Hi,

Balázs Lengyel  wrote:
> Hello Martin,
> I will update the draft following most of your comments. See details below.
> Regards Balazs
> 
> -Original Message-
> From: netmod  On Behalf Of Martin Bjorklund
> Sent: 2019. október 10., csütörtök 14:05
> To: netmod@ietf.org
> Subject: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04
> 
> Hi,
> 
> I have some mostly cosmetic comments on this draft.
>   o  "YANG" should be spelled "YANG".  Not Yang etc.
> BALAZS: OK
>   o  "NETCONF" should be spelled "NETCONF".
> BALAZS: OK
>   o  leaf-list module
> The type of this leaf-list is a string with:
>   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
> I think the revision needs to be optional, and the suffix ".yang"
> dropped, since it doesn't add any value:
>   pattern '.+(@\d{4}-\d{2}-\d{2})?';
>(same for inline-spec).
> BALAZS: I disagree, IMHO we need the revision date. We want to know the 
> exact version the data was produced against. If the version would be 
> unknown it might become very hard to understand whether the instance 
> data is correct or not.

The point is that the revision statement is optional in YANG.  If the
module doesn't have a revision statement I can't list it here.

> 
>   o  schema-uri
> The description says:
>   A reference to another YANG instance data file.
>   This instance data file will use the same set of target
>   YANG modules, revisions, supported features and deviations
>   as the referenced YANG instance data file.
> 
>I don't understand what this means.  Does it mean that the schema
>for this document is the same as the schema defined in the
>schema-uri file, or that the schema-uri file defines the schema in
>its content-data?
> 
>I *think* it is the former.  In either case, the name of the leaf
>can perhaps be changed to reflect the semantics, rather than the
>syntax (i.e., don't call it xxx-uri just b/c its type is an uri).
>Perhaps 'same-schema-as-file'.
> BALAZS:  OK, I changed the description hope it is easier to understand now.
> description
>   "A reference to another YANG instance data file.
>This instance data file will use the same
>content schema as the referenced file.";

Thanks, better.  Perhaps: s/will use/uses/

>   o  Data node naming.
> The current structure of the model is:
> +--rw (content-schema-spec)?
> |  +--:(simplified-inline)
> | +--rw module* string
> |  +--:(inline)
> |  |  +--rw inline-spec*string
> |  |  +--rw inline-content-schema   
> |  +--:(uri)
> | +--rw schema-uri?   inet:uri
> ...
> +--rw content-data? 
> 
> 
> To make the instance document more understandable, I suggest the
> following structure, which adds a wrapping container for the
> schema, and renames the inline and uri nodes:
> 
> +--rw content-schema
>+--rw (content-schema-spec)?
>|  +--:(simplified-inline)
>| +--rw module* string
>|  +--:(inline)
>|  |  +--rw inline-module*  string
>|  |  +--rw inline-schema   
>|  +--:(uri)
>| +--rw same-schema-as-file?inet:uri
> ...
> +--rw content-data? 
> BALAZS: OK, accepted
> 
>   o  Format the YANG module
> I suggest you run the YANG module through:
>   pyang -f yang --keep-comments --yang-line-length 69
> BALAZS: OK (I will do it, but I don't agree with a number of its formatting
> changes.
> 
>   o  3.2
> The element "" needs a namespace declaration.
> BALAZS: OK


/martin

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