[netmod] Please send you slides...

[Lou Berger]

Hi,

    All received slides received to date have been uploaded to 
https://datatracker.ietf.org/meeting/103/session/netmod


If you are on the agenda, please send your slides ASAP.  If you have 
already sent them, please confirm that they are posted at the above link.


Thank you!

Lou

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

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Balázs Lengyel]

  
  
Implementing 3.2 will be very costly. IMHO Ericsson will not
  implement it. We will do our utmost to avoid NBC changes, but if
  they do happen, I don't believe we would support multiple
  versions.

If the data models are sufficiently NBC e.g. changing a boolean
  to an integer 3.2 may not even be possible. The underlying data
  that drives the device may be an integer or a boolean, but not
  both. (Strange mapping may be possible to imagine, but they will
  not always work.)
regards Balazs


On 2018. 10. 27. 1:15, Robert Wilton
  wrote:


  
  
  
  
  On 26/10/2018 17:35, Andy Bierman
wrote:
  
  

  

  On Fri, Oct 26, 2018 at 2:33 AM,
Juergen Schoenwaelder 
wrote:
Let me add that
  there was large disagreement what a bug fix is in the
  design team. Hence, any text that talks about 'bug
  fixes' is ambiguous
  and of limited value to achieve consensus. (Or we may
  find consensus
  but then not agree on what we have found consensus
  on.)
  
  To be more concrete, I learned that Rob's notion of a
  bug fix is very
  different from my notion of a bug fix. I think it is
  important for
  having a productive discussion to be aware of this.
  
  For me, a bug fix is rather limited, i.e., fixing
  something where the
  correct intention was clear but the model did not
  properly capture the
  intention correctly, i.e., roughly what we can do with
  errata in the
  IETF. I think Rob understands bug fixes in a much
  broader sense,
  including fixes to what essentially are in my view
  module design
  errors.
  
  With my narrow definition of bug fixes, bug fixes are
  essentially
  backwards compatible (even if they may violate RFC
  7950 rules - but as
  long as the original intention was clear, we can be
  flexible).
  
  With Rob's notion of bug fixes, we have to handle them
  as part of the
  versioning system since they may be non-backwards
  compatible.
  





IMO requirements 3.1 and 3.2 are the most
   important and have the most impact
on the solution space. I do not agree with either
  of these requirements.
  

  

  
  OK.
  
  For 3.1, I think that just means that the solution has to be
  backwards compatible with existing clients (e.g. don't change the
  protocols in a non backwards compatible way).
  
  

  

  


Implementing multiple non-compatible revisions of a
  module on a server sounds hard,
not to mention that it breaks RFC 7950 rules. 
  

  

  
  Completely agree that it will be hard.  I envisage that it will
  optional for servers to implement this.
  
  

  

  
The current protocols do not support the
ability to specify different versions of the same
  QName. This change makes YANG validation
much to difficult to specify and implement (as that
  has to be rewritten as well).
  

  

  
  The way that I think of one solution for this problem is using
  datastore schema (as per the NMDA definition):
  
  Say for release X, the server natively supports Module A@ver1.0.0 and ModuleB@ver1.0.0, call this schema X.
  For release Y, the server natively supports Module A@ver1.1.0 and ModuleB@ver2.0.0, call this schema Y.
  
  When a client connects it chooses which schema it wants to use, X,
  Y, or latest.  If it doesn't specify then perhaps it uses the
  earliest schema (to handle requirement 3.1).
  
  If the client wants to use X, then the server has to translate the
  request into the equivalent request using schema Y instead. 
  Perhaps the server has to validate the config both in the context
  of X and Y.
  
  If the clients wants to 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Balázs Lengyel]

Hello,

Deprecate and startover today, with the current definition of 
deprecated, allows: remove and startover. The server is not mandated to 
support deprecated nodes.


Deprecating/Removing stuff is not just backwards incompatible, it also 
leads to the client not knowing whether deprecated stuff is supported or 
not. So IMHO anything is better then the current deprecated.


regards Balazs

On 2018. 10. 27. 20:50, Andy Bierman wrote:
IMO the current "deprecate and start over" is actually the easiest and 
most robust

solution path, and it requires no changes to YANG or the protocols.


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