Subject: [netmod] draft meeting minutes from Interim meeting on June 18, 2015

From: Nadeau Thomas <[email-masked]>
Date: Thu, 25 Jun 2015 09:26:37 -0400

These are the draft meeting minutes from Interim meeting on June 18, 2015. Please comment. If I don’t hear from anyone by Friday, they will be published as-is.

	—Tom

NETMOD Virtual Interim Meeting (June 18, 2015)

* Participants

- Acee
- Ambika Prasad Tripathy
- Andy Biermann
- Anees Shaikh
- Benoit Claise
- Einar Nilsen-Nygaard
- Martin Bjorklund
- Harish
- Helen Chen
- Ignas Bagdonas
- Jeffrey Haas
- Kent Watsen
- Lou Berger
- Mahesh Jethanandani
- Marcus Hines
- Norm Strahle
- Qin Wu
- Rob Shakir
- Robert Wilton
- Shitanshu Shah
- Steve Ulrich
- Susan Hares
- Thanasis Kypartis
- Vishnu Pavan Beeram
- Lada Lhotka
- Xufeng Liu
- Yingzhen Qu

Agenda:
- Agenda Bashing
- draft-openconfig-netmod-opstate-00
- draft-openconfig-netmod-model-structure-00

Meeting starting. 
Anees presenting: 
Now Rob Shakir presenting:
    Draft: http://tools.ietf.org/html/draft-openconfig-netmod-opstate-00
    Slides: http://www.openconfig.net/file-cabinet/netmod-interim-opstate.pdf?attredirects=0&d=1
    
    https://www.ietf.org/proceedings/interim/2015/06/18/netmod/slides/slides-interim-2015-netmod-13-0.pdf

* Slide #2

  KW: Is the request for consistent state true for all three kinds of operational state?
  RS: Yes
  AS: It is important that all the state is in a consistent place that is easy to find by automated tools.

* Slide #3

  LL: Is intended configuration the same as config true in YANG and applied/actual/operational state is config false in YANG?
  RS: yes
  MH: Is config for a line card not present intended or applied state?
  JH: is there a distinction between counters that are never intermingled with config true nodes?
  BC: You only want an operational true flag, not a distinction between statistics, actual, applied, ... state?
  AS: Operational true is a subset of the config false data. The motivation is to be able to get only the config false data where the device has determine the value on its own (that is, the value does not come from the config).
  MB: Is operational true only needed if you have the config in the same data tree?
  RS: yes
  RS: I need a way to get all the config false leafs or the operational true leafs (as defined above).
  MB: There may be several solutions, one of them could be a separate datastore with the same data model.
  KW: I think I understand synchronous means a commit makes the operational state reflect the config state.
  KW: And an asynchronous system would not immediately reflect the config state in operational state after the commit.
  KW: Is this defined in NETCONF?
  MB: A successful write to :running means that config is valid and will be applied but you can have config for non-existing line cards etc.
  MB: I would add an axiom: Any solution should work with NETCONF.
  LL: What about hostname set by a CLI - is this intended or applied or ... state?
  RS: In cases where there are multiple writers, the need for retrieval of operational state becomes important.
  BC: In a synchronous system, does it make sense to replicate data?
  RS: There are always parts of a device where systems tend to be not synchronous.
  RS: On the wire, duplication may be dealt with by proper design of RPCs.
  MB: I am concerned about large and complex data models with almost redundant definitions.
  AB: Yes, this sounds more like a protocol problem than a data model problem.
  RS: It is a one-time pain for a module writer.
  RS: Do we optimize for module writers or for NMS writers?
  LL: I do not understand applied operational state and the other operational state.
  RS: YANG config true = intended state, operational state derived from config true (intended state) = applied state, other operational state is the remaining state not resulting from config.
  RS: YANG config true => intended and applied state, YANG config false => operational state
  MB: The terminology confusion needs to be resolved.
  MB: Intended config is my configuration file, once loaded, it becomes applied config?
  KW: I continue to be confused by the terms synchronous and asynchronous.
  MB: Are not all systems asynchronous in your definition? Are there examples of synchronous systems?
  RS: Intended config means syntactically correct. This does not mean that a system will actually be able to apply it.
  AB: A NETCONF OK means more than syntactically correct (e.g. if you write the <running> datastore).
  TN: One hour gone, we made it to slide #3 out of 9.
  RS: We do not want to tightly couple this to NETCONF semantics.
  MB: But we are trying to understand your concepts from a NETCONF perspective.
  AB: I like to avoid rewriting RFCs.
  AT: Syntax checking is already part of YANG.
  RS: Intended config is expected to be syntactically valid, it still may not be applied without failures.
  JH: What do you mean when you use the term RPC?
  JH: is committed config (running datastore) == intended config?
  RS: yes
  JH: The active state is usually a different node in the data tree, different from the config state.
  RS: No, they have different branches in our proposal.
  AB: We should keep the model stateless as much as possible, the distinction needs to happen at the protocol.
  MB: The duplication of intended and applied config does not seem to be necessary. Note that there is more, a startup value, an ephemeral value, etc.
  AB: proposal may not take into account Benoit's draft re: other SDO moudles
  KW: start-up/candidate datastores not relavent.  running datastore == "intended".  how running is set (via wriatable-running or candaidate commit) not important.  Operational state isn't related to datastore. e.g., not such thing as operational state of startup or candidate datastore.  Not clear if oprerational is even part of running datastore, or if it's more like another datastore that happens to have running datastore values intermingled in it...

* Slide #4/#5 (somehow)

  MB: There are semantics how leafs are related to each other that go beyond simply naming conventions.
  RS: I can easily check whether intended state == applied state and I can easily obtain the related operational state.
  AB: Putting things under a certain container is not needed since you can define RPCs that have the proper semantics.
  RS: Do not just think NETCONF, there will be other systems involved.
  AB: I think JH stated the requirement that being able to retrieve the state data associated with a resource.
  JH: They are trying to use YANG for models that are not used with NETCONF.
  RS: But we have conventions and coding styles in many other languages.
  AB: There are rules for identifiers and they do not distinguish different combinations of characters to mean different things.
  KW: We need to define clear terminology and we should go back to the problem description.

Back to slide #3:
  MB/KW: definition of intended vs applied raised again, are they not the same given all servers are effectively assyncrounous?
  BC: recommandation to clarify  
  ACTION ITEM for the authors: terminology 
    - for intended, applied
    - synchronous/asynchronous
ACTION ITEM for the authors: 
    - example of full NETCONF synchronous: RPC and datastore/leaf update. What are the consequences? duplicate leaf in /config and /state
    - example of (non-NETCONF) asynchronous: RPC and datastore/leaf update
  KW: NETCONF/RESTCONF are synchronous protocols but state application are applied asynchronously.
  RS: We like to have distinctions in the data model so that they are protocol agnostic.
  
  TN: Can we articulate a clear problem statement after almost two hours?
  AS: some agreement in understanding, some distance in solution.  need to clear up terminology

Wrap-up: review of requirements on slides 2 and 3
      
  Slide #2: 
    - point 1: clear, and we have agreement (already the case with config=false statement)
    - point 2: not clear
    - point 3: clear, and we have agreement
      - though re: point #3, JS questions if any YANG statements are NETCONF specific
      - AS says that it's really a statement about the protocol so the wording is a bit misleading

  Slide #3
    - point 1: not clear (most likely due to terminology)
    - point 2: clear and agreed (already the case)
    - point 3: not clear (again most likely a terminology issue)

MEETING ENDED @ 12:15 Eastern