Re: [netmod] instance data new backward compatibility text

[Martin Bjorklund]

Hi

I agree with Juergen.  I think section 6 should be removed.  This
document should specify the document format (which it does), but it
shouldn't specify specific rules for the different use cases.


/martin


Juergen Schoenwaelder  wrote:
> Your rules are use case specific and I am not convinced they are
> applying to all use cases. It should be a perfectly valid use case to
> store snapshots of  in instance data files. Your rules do not
> make sense here and I do not think this is a valid usage of the SHOULD
> mechanism.
> 
> /js
> 
> On Mon, Mar 25, 2019 at 11:01:52PM +, Balázs Lengyel wrote:
> >Hello Jurgen,
> > 
> >I don't think these rules are Ericsson specific. In some of our most
> >important use-cases (UC1, UC2, UC6) changing the keys would lead to
> >problems.
> > 
> >UC1: If you document server capabilities using ietf-yang-library the name
> >of the module sets may be/should be meaningful. It might be used by the
> >NMS to compare the capabilities of different versions of the YANG server;
> >changing keys without a reason will mislead the NMS into assuming the
> >server capabilities changed..
> > 
> >UC2: Preloading default configuration data. E.g. If you change the
> >identifier of NACM ruleset, then during upgrade it might be loaded again
> >as the server can not detect, that this is the same ruleset that is
> >already in the datastore.
> > 
> >UC6:Â Storing diagnostics data. If you change the keys used in diagnostic
> >data, comparing values before and after the key change will be difficult.
> > 
> >And yes as we were using instance data for the last then years, we did
> >have a lot of problem with people changing the keys without considering
> >compatibility effects.
> >I agree that this is not always a problem, so I only used SHOULDÂ (and 
> > not
> >MUST) in the text.
> > 
> >regards Balazs
> > 
> > 
> >On 2019. 03. 25. 23:16, Juergen Schoenwaelder wrote:
> > 
> >  On Mon, Mar 25, 2019 at 09:59:43PM +, Balázs Lengyel wrote:
> > 
> >  Hello Jurgen,
> > 
> >  You are right that this is important mostly for instance data prepared as a
> >  design/implementation activity; while not relevant for data coming from the
> >  node.
> >  I will add it.
> > 
> >  However in the first case it is vital!
> > 
> >  For config files, and also for file documenting server capabilities we have
> >  had MANY problems with people changing the key values/identities of list
> >  entries.
> >  They think it is a nice idea to provide better, more meaningful key values;
> >  however the NMS designers use these key values to detect changes; also
> >  during an upgrade process if a default configuration file is loaded again
> >  with slightly changed key values, then e.g. access control rules become
> >  duplicated.
> > 
> > 
> >  The conditions under which it is meaningful to change keys and when it
> >  is not appropriate are very application specific.  You may have
> >  specific use cases at Ericsson where you want internal regulations but
> >  I do not think this leads to meaningful rules outside your specific
> >  application scenario.
> > 
> >  /js
> > 
> > 
> >  --
> >  Balazs Lengyel   Ericsson Hungary Ltd.
> >  Senior Specialist
> >  Mobile: +36-70-330-7909  email: 
> > [1]balazs.leng...@ericsson...com
> > 
> > References
> > 
> >Visible links
> >1. mailto:balazs.leng...@ericsson.com
> 
> 
> 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> -- 
> 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

Re: [netmod] instance data new backward compatibility text

[Juergen Schoenwaelder]

Your rules are use case specific and I am not convinced they are
applying to all use cases. It should be a perfectly valid use case to
store snapshots of  in instance data files. Your rules do not
make sense here and I do not think this is a valid usage of the SHOULD
mechanism.

/js

On Mon, Mar 25, 2019 at 11:01:52PM +, Balázs Lengyel wrote:
>Hello Jurgen,
> 
>I don't think these rules are Ericsson specific. In some of our most
>important use-cases (UC1, UC2, UC6) changing the keys would lead to
>problems.
> 
>UC1: If you document server capabilities using ietf-yang-library the name
>of the module sets may be/should be meaningful. It might be used by the
>NMS to compare the capabilities of different versions of the YANG server;
>changing keys without a reason will mislead the NMS into assuming the
>server capabilities changed..
> 
>UC2: Preloading default configuration data. E.g.� If you change the
>identifier of NACM ruleset, then during upgrade it might be loaded again
>as the server can not detect, that this is the same ruleset that is
>already in the datastore.
> 
>UC6:� Storing diagnostics data. If you change the keys used in diagnostic
>data, comparing values before and after the key change will be difficult.
> 
>And yes as we were using instance data for the last then years, we did
>have a lot of problem with people changing the keys without considering
>compatibility effects.
>I agree that this is not always a problem, so I only used SHOULD� (and not
>MUST) in the text.
> 
>regards Balazs
> 
> 
>On 2019. 03. 25. 23:16, Juergen Schoenwaelder wrote:
> 
>  On Mon, Mar 25, 2019 at 09:59:43PM +, Bal�zs Lengyel wrote:
> 
>  Hello Jurgen,
> 
>  You are right that this is important mostly for instance data prepared as a
>  design/implementation activity; while not relevant for data coming from the
>  node.
>  I will add it.
> 
>  However in the first case it is vital!
> 
>  For config files, and also for file documenting server capabilities we have
>  had MANY problems with people changing the key values/identities of list
>  entries.
>  They think it is a nice idea to provide better, more meaningful key values;
>  however the NMS designers use these key values to detect changes; also
>  during an upgrade process if a default configuration file is loaded again
>  with slightly changed key values, then e.g. access control rules become
>  duplicated.
> 
> 
>  The conditions under which it is meaningful to change keys and when it
>  is not appropriate are very application specific.  You may have
>  specific use cases at Ericsson where you want internal regulations but
>  I do not think this leads to meaningful rules outside your specific
>  application scenario.
> 
>  /js
> 
> 
>  --
>  Balazs Lengyel   Ericsson Hungary Ltd.
>  Senior Specialist
>  Mobile: +36-70-330-7909  email: [1]balazs.leng...@ericsson..com
> 
> References
> 
>Visible links
>1. mailto:balazs.leng...@ericsson.com



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


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

Re: [netmod] instance data new backward compatibility text

[Balázs Lengyel]

  
  
Hello Jurgen,
I don't think these rules are Ericsson specific. In some of our
  most important use-cases (UC1, UC2, UC6) changing the keys would
  lead to problems.
UC1: If you document server capabilities using ietf-yang-library
  the name of the module sets may be/should be meaningful. It might
  be used by the NMS to compare the capabilities of different
  versions of the YANG server; changing keys without a reason will
  mislead the NMS into assuming the server capabilities changed.. 
UC2: Preloading default configuration data. E.g.  If you change
  the identifier of NACM ruleset, then during upgrade it might be
  loaded again as the server can not detect, that this is the same
  ruleset that is already in the datastore.

UC6:  Storing diagnostics data. If you change the keys used in
  diagnostic data, comparing values before and after the key change
  will be difficult.
And yes as we were using instance data for the last then years,
  we did have a lot of problem with people changing the keys without
  considering compatibility effects.
  I agree that this is not always a problem, so I only used SHOULD 
  (and not MUST) in the text.

regards Balazs


On 2019. 03. 25. 23:16, Juergen
  Schoenwaelder wrote:


  On Mon, Mar 25, 2019 at 09:59:43PM +, Balázs Lengyel wrote:

  
Hello Jurgen,

You are right that this is important mostly for instance data prepared as a
design/implementation activity; while not relevant for data coming from the
node.
I will add it.

However in the first case it is vital!

For config files, and also for file documenting server capabilities we have
had MANY problems with people changing the key values/identities of list
entries.
They think it is a nice idea to provide better, more meaningful key values;
however the NMS designers use these key values to detect changes; also
during an upgrade process if a default configuration file is loaded again
with slightly changed key values, then e.g. access control rules become
duplicated.


  
  
The conditions under which it is meaningful to change keys and when it
is not appropriate are very application specific.  You may have
specific use cases at Ericsson where you want internal regulations but
I do not think this leads to meaningful rules outside your specific
application scenario.

/js



-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] instance data new backward compatibility text

[Juergen Schoenwaelder]

On Mon, Mar 25, 2019 at 09:59:43PM +, Balázs Lengyel wrote:
> Hello Jurgen,
> 
> You are right that this is important mostly for instance data prepared as a
> design/implementation activity; while not relevant for data coming from the
> node.
> I will add it.
> 
> However in the first case it is vital!
> 
> For config files, and also for file documenting server capabilities we have
> had MANY problems with people changing the key values/identities of list
> entries.
> They think it is a nice idea to provide better, more meaningful key values;
> however the NMS designers use these key values to detect changes; also
> during an upgrade process if a default configuration file is loaded again
> with slightly changed key values, then e.g. access control rules become
> duplicated.
>

The conditions under which it is meaningful to change keys and when it
is not appropriate are very application specific.  You may have
specific use cases at Ericsson where you want internal regulations but
I do not think this leads to meaningful rules outside your specific
application scenario.

/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

Re: [netmod] instance data new backward compatibility text

[Balázs Lengyel]

Hello Jurgen,

You are right that this is important mostly for instance data prepared 
as a design/implementation activity; while not relevant for data coming 
from the node.

I will add it.

However in the first case it is vital!

For config files, and also for file documenting server capabilities we 
have had MANY problems with people changing the key values/identities of 
list entries.
They think it is a nice idea to provide better, more meaningful key 
values; however the NMS designers use these key values to detect 
changes; also during an upgrade process if a default configuration file 
is loaded again with slightly changed key values, then e.g. access 
control rules become duplicated.


regards Balazs

On 2019. 03. 25. 14:19, Juergen Schoenwaelder wrote:

Hi,

I am not sure why we have this new section. The notion of backwards
compatibility for instance data is somewhat dubious. There text that
is there now is potentially even harmful or it needs to be ignored. If
I dump datastore content into an instance file, I get what I get. The
text that is there may help with maunally edited instance files but
this is where it ends. My proposal is to simply drop section 6 again.

/js


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod