Subject: [netmod] Interim Meeting Minutes June 25, 2015

From: Nadeau Thomas <[email-masked]>
Date: Mon, 6 Jul 2015 09:34:05 -0400

These are the preliminary notes from the interim meeting on June 25, 2015.  I am still awaiting notes from Ignas who also took meeting minutes before I post the official minutes.  If there are any comments/corrections to what I have below, please post here as soon as possible. 

	—Tom

NETMOD Virtual Interim Meeting (June 25, 2015)

* Participants
  - Acee (AC)
  - Alia Atlas
  - Andy Bierman
  - Anees Shaikh
  - Aseem Choudhary
  - Balazs Lengyel
  - Benoit Claise
  - Clyde Wildes
  - Dan Romascanu
  - Einar
  - Giles
  - Ignas Bagdonas
  - Jason Sterne (JS)
  - Kent Watsen
  - Mahesh Jethanandani
  - Marcus ????
  - Martin Bjorklund
  - Phil Shafer
  - Qin Wu
  - Robert Wilton
  - Sam Aldrin
  - Susan Hares
  - Tarek Saad
  - Tom Nadeau
  - Vishnu Pavan Beeram
  - Xufeng Liu
  - Yingzhen Qu

Meeting starting  (10:06am ET)
  
Agenda:
    - Agenda Bashing
    - draft-openconfig-netmod-opstate-00
    - draft-openconfig-netmod-model-structure-00

Anees Presenting
Going over terminology based on slides exchanged over e-mail. Applied/actual configuration should not be fetched when a yet to be defined <get-oper> is defined. In other words, get operational should fetch only protocol negotiated values and counters. This would require a flag other than config = false to be defined.
  - KW: is the applied/actual having the value "auto"?
  - AS: yes
  - KW: would the term "distributed" be better?
  - AS: no
  - JS: how far do we need to go to consider a config node "applied"? (e.g., distributed systems)
  - AS: systems will differ, what matters is what they perceive to be applied
  - SH: where would ephemeral state be catured?
  - AS: it's not captured in this model, but makes sense to view as intended config that is not persisted
  - MB: where would interfaces configured by system (not user-configured) be captured in this model?
  - AS: should be part of intended config
  - MB: so system should update intended config to capture/add these additional nodes
  - M?: should show up in applied config (not intended)
  - MB: so applied config can contain more than just intended config...
  - AB: applied state a child of indended state?
  - MB: right, since parent is config=true
  - RW: given interfaces MAY have config, then an unconfigured interface (line card plugged in) still takes default config, no?
  - AS: makes sense that there are some default config values applied to it, just not from intended config
  - SH: ephemeral operational state goes into operational state too?
  - AS: yes
  - AB: proposal about data organization, but there is a yang statement too
  - AS: no, proposal has both.  
  - AB: Disagree duplicating data-model nodes, scales better to use datastores [KW: Juergen made same point on list]
  - AS: 
  - MB: agree that should be possible to use w/o NC, but datastores aren't NC-specific either [witness RC]
  - TN: isn't this the same thing? - two option: decorate model vs add an operation
  - BL: protocol option better, as otherwise it would grow the saize of the model greatly
  - AS: putting it into the model (data structure) can be simpler
  - MB: is 9/10 follow model-structure, but 10th doesn't, even though valid YANG, the whole thing falls down
  - AB: overloading names could cause conflict - e.g., an address book's "State" value
  - AS: may not be important to standardize models at this stage, without much much operational experience, not too much value in existing models
  - BC: do we have people that want to work on an optional proposal?  [no one steps forward]

Moving on to model-structure draft  (10:58am ET)
  - Anees presenting
  - MB: how is putting a device node under arbitrary parent?  
  - AS: useful anchor point, not stricly necessary but very useful and don't see anything harmful in it
  - AB: adds more payload to every message in every protocol
  - AS: don't understand payload comment
  - AB: adds string to instance-identifier
  - BL: ex: alarm, the length of the instance-identifier is an important point
  - MB: what's the point of having top-level "/device", why not just "/"? 
  - PS: more than that... <i missed it>
  - AS: so bring up everything one level would be better?
  - MB: yes
  - AS: yeah, i agree
  - AA: what is the argument behind having "/device"?  - string length?
  - AB: no value
  - AS: thought a single anchor would be useful
  - BC: regardless of single anchor, is there agreement of having any common anchor points?
  - AB: likes catalog part
  - BC: likes it too, who would organize it?
  - KW: like catalog too, but thinks the catalog should also contain transformation to/from lower-level models
  - AS: agrees that there can be a multiplicity of top-level models
  - TN: this may need to be an informational draft
  
Moving on to Meta-Model Structure slides (Acee presenting)
  - JS: re: logical network level, should different logical routers have different NETCONF sessions?
  - AC: sounds like an SNMP like solution
  - SH: why policy under each protocol as opposed to at the top?
  - AC: it's like an object can be applied to each protocol
  - BC: how far we with YANG1.1 and is there anything useful in it for routing design team?
  - MB: ~1 open issue left and then will publish draft, should be ready for WGLC.  
  - BC: when Y1.1 is published, we'll need to advertise it to other design teams

[Meeting Ends @ 11:50am ET]