Minutes for NETMOD at IETF-92
minutes-92-netmod-2

=============================================================
NETCONF Data Modeling Language WG (netmod)
IETF #92, Dallas, USA
Monday, Mar 23rd, 2015, 09:00-11:30, Gold
Tuesday, Mar 24th, 2015, 09:00-11:30, Gold
Minutes Juergen Schoenwaelder, Dean Bogdanovic
=============================================================

WG Chairs: Thomas Nadeau
           Juergen Schoenwaelder
WG URL:    http://tools.ietf.org/wg/netmod/
Jabber:    xmpp:netmod@jabber.ietf.org

Agenda:

   Monday (2015-03-23):
    1. Administrivia (10 min)
    2. YANG 1.1 (60 min)
    3. YANG Guidelines Update (10 min)
    4. JSON Encoding of YANG Data (20 min)
    5. Defining and Using Metadata with YANG (20 min)
    6. AOB (YANG Language and Infrastructure) (5 min)
    7. SYSLOG Data Model (20 min)
    8. Entity-MIB Yang Model/Design Team Update (5 min)
    9. Inventory Data Model (5 min)

   Tuesday (2015-03-24):
    1. Administrivia (10 min)
    2. YANG Model Coordination (5 min)
    3. ACL Data Model (15 min)
    4. Core Routing Data Model (20 min)
    5. Data Model Classification (15 min)
    6. Consistent Modeling of Operational State Data (20 min)
    7. Operational Structure and Organization of YANG Models (15 min)
    8. Diffserv Data Model (10 min)
    9. Peer Mount Requirements (5 min)
   10. AOB (Data Modeling)
   
Summary:

  The NETMOD working group met twice during IETF 92 in Dallas.  The
  meetings (Monday 09:00-11:30 and Tuesday 09:00-11:30) were attended
  by about 120 people in each session. The YANG 1.1 effort has been
  working on closing the remaining issues. A complete revised
  specification is expected to go to WG last call in April. The work
  on the YANG guidelines document update will follow once YANG 1.1 is
  stable. The JSON mapping will be revised and cover YANG 1.0 and 1.1.

  The data models worked on by the NETMOD working group (core routing,
  syslog, ACLs) are progressing with the authors primarily resolving
  review comments. Some routing data model related design issues have
  been resolved. A design team recently formed to work on a data model
  for physical components (based on the SNMP ENTITY-MIB) has met at
  the IETF. Additional working group discussions centered around the
  question how to classify and how to organize data models. Finally,
  work on a data model for Differentiated Services has been presented.
		
Slides:

  http://www.ietf.org/proceedings/92/netmod.html

Audio:

  http://www.ietf.org/audio/ietf92/

Meetecho:

  http://ietf92.conf.meetecho.com/index.php/Recorded_Sessions

Actors:

  - JS = Juergen Schoenwaelder
  - TN = Thomas Nadeau
  - AB = Andy Bierman
  - MB = Martin Bjorklund
  - LL = Ladislav Lhotka
  - BC = Benoit Claise
  - KW = Kent Watsen
  - BL = Balazs Lengyel
  - PS = Phil Shafer
  - BW = Bert Wijnen
  - AS = Anees Shaikh
  - DB = Dean Bogdanovic
  - PH = Peter van Horne
  - CW = Clyde Wildes
  - JD = Jie Dong
  - SH = Susan Hares
  - JT = Jason Stern
  - AL = Acee Lindem
  - JH = Jeffrey Haas 
  - SL = Stephane Litkovski
  - AA = Alia Atlas
  - RS = Rob Shakir
  - JZ = Jeffrey (Zhaohui) Zhang
  - MJ = Mahesh Jethanandani
  - KS = Kevin D'Souza
  - EO = Eric Osbourne
  - AC = Alex Clemm
  - NS = Norm Strahle
  - EV = Eric Voit

Meeting Notes:

* YANG 1.1

** VRFY :Y34: remove/deprecate/replace the 'anyxml' statement
    
   The current solution proposal is Y34-05. No comments in the room.

** VRFY :Y45: better conformance mechanism

   The current solution proposal is Y45-02.

   LL: I am not very happy with this solution, it is way too strict.
   LL: I think we should have a solution that works with imports.
   MB: Solution Y45-02 seems to be the only one handling all aspects
       and import-by-revision does not work.
   MB: Import by revision everywhere leads to update ripple effects.
   LL: There is not ripple problem, implementations have to deal with
       multiple modules at different revision levels.
   AB: I agree with Martin that the ripple effect is a problem. When
       you want to use a new version of a module, you have to update
       everything else that you use from the same module.
   AB: I like the fact that you have to make an explicit change if
       you want to use a new version of a typedef/grouping.
   PS: The cost should be on the person who uses definitions. If
       someone does not want to use the new definition, he/she could
       copy the old definition into his own module.
   JS: The problem with this is that you end up with a larger number
       of modules that have copied a common definition and from there
       on the N copies life a life on their own.
   PS: It should be a decision of the owner of the module whether an
       old definition is kept or not.
   LL: I do not know how often it will happen that people want to stick
       with old definitions; I kind of agree with PS.
   MB: We have been discussing this for almost a year. At this point,
       if someone has a new / better solution, we need a concrete
       proposal not just some rough idea.
   JS: There are many details that interact here. You can easily solve
       every detail alone but then things fall apart if you look at
       the global picture. The current solution proposal is very
       simple but you publish definitions without knowing who is 
       using definitions. There are no side-effect changes, authors 
       have to explicitly adopt new versions of definitions and they
       do not have to check themselves whether any of the imported
       definitions has semantically changed.
   AB: Import by revision is not used everywhere and it is actually
       a burden to maintain the revision dates current during the
       development process.
   AB: Copying definitions into a local module seems to be a bad 
       solution since it is at odds of having common definitions in
       the first place.
   PS: I understand that Y45-02 is the simplest answer. But it is 
       also the most expensive and painful.
   JS: We are going to send Y45-02 out for verify. But note that it
       will not be sufficient I do not like Y45-02, to make progress,
       it will be required to describe a new solution that does work.
       Please check against the I-Ds AB and MB posted on the issues.
       We have spent an extensive amount of time on Y45 and it is
       time to wrap this up.       

** OPEN :Y26: allow mandatory nodes in augment

   MB explains the two proposals Y26-01 and Y26-02.

   LL: I do not think we can specify rules that cover all situations.
       My suggestion is to allow mandatory nodes in augments.
   AB: Does this must statement only apply for updates?
   AB: The case I am most concerned about is that a vendor introducing
       module Y should not break an existing module X.
   AB: I do not think we should allow breaking modules via mandatory
       things in an augment.
   LL: The presence container does not really make the new leafs
       mandatory. Other constraints (must and when expressions) can
       also break modules. I prefer guidelines text. Some of our
       data models are designed to augment significant portions into
       a core model.
   PS: Y26-02 adds the cost of an additional container but the contract
       of the augmented module is preserved and this matters.

   The opinion in the meeting was leaning towards Y26-02.

** OPEN :Y36: associate a notification with a data node

   MB explains the proposals. Y36-01 keeps notifications on the
   top-level while Y36-02 puts notification definitions inline. The
   discussions seems to be around the question how to encode these
   inline notifications in NETCONF.

   AB: One goal was to simplify access control, Y36-01 does not
       help us with that.
   JS: Is it possible to get some volunteers to look into Y36 in
       order to work out an encoding proposal? Some people agreed
       to look into the encoding aspects.
   BL: If this is only for symmetry, then I do not support this.
   JS: The benefit is simplified access control.

** OPEN :Y57: non-unique leaf-list

   MB explains the issue and that proposals are documenting the
   history of solution development. The current solution proposal 
   is Y57-03 (which is an updated version of Y57-01 and Y57-02).

   MB: I am concerned making a lot of changes for a relatively small
       use case and it affects how updates are made.
   AB: Addressing by position is fragile. A leaf-list is a derivative
       case of a list where the list has only a key.
   LL: This does not make much sense of system-ordered leaf-lists. For
       an AS path, the work-around is introducing a list but it would
       be really helpful in this case. This should be restricted to
       user ordered lists.
   BL: I posted the solution a couple of weeks ago and nobody raised
       any issues so far.

   JS asks who has read the proposal and out of those who think the
   solution proposal is sound and complete. A few people had read the
   complete proposal and most of them felt the proposal is sound and
   complete.

   JS reminds people that we had another issue Y09 to introduce
   optional keys which after quite some discussion has been moved to
   DEAD for YANG 1.1. This current issue Y57 seems to be related and
   the solution requires to introduce addressing by position. The
   question is whether the gain given by Y57 is worth the effort of
   adding addressing by position.

   The opinion in the meeting was two supporting Y57-03 against a few
   not supporting Y57-03. This did not look like strong consensus for
   making this change.

   PS: How do we decide what to add and what not to add?
   JS: We go through all issues and for each of them we analyze the
       trade-offs (benefits of the change, costs of the change, ...)
       and then we try to find consensus.
   PS: If you do not adopt it, then the data model needs to make an
       artificial key. If you adopt it, then position oriented edits
       need to be supported by servers.
   PS: I find the solution proposal that a delete of <value>a</value>
       deletes only the first <value>a</value> and I have to send N
       times <value>a</value> to delete all N values 'a' surprising.
       I would prefer if a delete of <value>a</value> would delete
       all values 'a'. The whole idea of manipulating sub-members
       of a list by position seems awkward.
   JS: Yes, it is something we do not do anywhere else.
   BW: Two voices in favor is not a strong position to add something.
   BL: Even today, we do not have a way to handle a leaf-list as a unit.
       If we want to change the semantics, this can be done.
   JS: It could be done is probably not sufficient. We need to see the
       value of the change with regard to the costs it has.
   AB: One area where it breaks, we do not have something like if match
       in NETCONF. Things so far are always identified by their name but
       never by their value or position.
   BW: For a big and not so simple change, I think you need more than
       two people in favor.

   It seems the meeting does not have sufficient support for adopting
   Y57-03.

** NEW :Y60: coexistence with YANG 1.0

   Several questions need to be addressed in a coexistence section.
   - Will YANG 1.1 obsolete YANG 1.0 or not?
   - YANG 1.1 modules importing from YANG 1.0?
   - YANG 1.0 modules importing from YANG 1.1?
   - ...

   AS: Given the state of deployment we have, can we not obsolete 1.0
       right now?
   JS: I think the procedural question is less problematic. We do have
       YANG 1.0 data models published. Perhaps we keep YANG 1.0 alive
       until all YANG 1.0 modules can revised naturally and we might
       require all new modules to be YANG 1.1.
   DB: We should leave some time for implementations to catch up and
       to migrate to YANG 1.1. There are many YANG models outside the
       IETF.
   JS: At this point in time, lets simply make Y60 an OPEN issue and
       the text for this section will be worked out when the other
       edits of the YANG 1.1 document are finalized.
   AB: You can't use YANG 1.1 in reusable modules until the general
       infrastructure is ready to support YANG 1.1.

   The meeting supported to move Y60 from NEW to OPEN.

** Actions

   - JS: post VRFY on Y34-05
   - JS: post VRFY on Y45-02
   - JS: post VRFY on Y26-02
   - JS: report Y36 encoding meeting results
   - JS: post VRFY for moving Y57 to DEAD
   - JS: post VRFY for moving Y60 to OPEN

* YANG Guidelines Update

  AB presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-6.pdf

  BC: Prefixing examples with a common prefix and/or using the CODE
      BEGINS convention. The later has relations to license regulations.
  JS: The CODE BEGINS convention was introduced to support automated
      extraction of YANG modules, not for license issues.
  BC: There is text in the IETF trust web page, I will forward it to
      the list.
  DB: Using a special tag EXAMPLE BEGINS is likely easier.
  BC: There is the convention of using ACME and since we will soon
      have a WG with that name.
  BW: An example may be incomplete and not necessarily compile clean.
  JS: We will settle this likely with the help of the yang-doctors
      mailing list.

  LL: When expressions on different leafs have different context nodes
      (slide 5) and hence even if they mean the same, the expressions
      will be different. We should avoid redundant when expressions.
  MB: I think we decided to not allow this for keys in YANG 1.1.
  AB: I want to change a module to YANG 1.1 without anything breaking.
  MB: In certain cases, you will have to make some edits since YANG
      is in a few places more restrictive.
  TN: Do we need YANG 1.0 guidelines and YANG 1.1 guidelines?
  AB: No, we will move to YANG 1.1 and YANG 1.0 becomes history.
  AB: There is likely not a problem here since you can't have 
      conditional keys anyway.
  MB: We might not need a guideline on this since YANG 1.1 has an
      explicit rule for this.

  AB: The augment with mandatory nodes issue (slides 6-7) might be
      obsolete now given the discussion of Y26 a couple of minutes
      ago.

  MB: There is already text in 6020bis concerning 64-bit numbers
      (slide 8) and hence additional text may not be needed.

** Actions

   - AB: Go through the mail archives to find any missed issues
   - AB: Go through YANG 1.1 issues to find any missed issues

* JSON Encoding of YANG Data

  LL presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-5.pdf

  PH: Do you have any idea when RESTCONF will become RFC?
  JS: You have to ask other people, come to the NETCONF meeting
      tomorrow.
  PS: I am confused by your interpretation of anyxml. I do not
      understand the rationale.
  LL: Anyxml is just anyxml since there was only NETCONF (which uses
      XML) when YANG was created.
  PS: You are saying anyxml is any data in any format?
  LL: The issue of transforming XML to JSON is not addressed by
      this document. If an anyxml node needs rules, then the data
      model writer has to specify the rules.
  MB: Since we add anydata to YANG 1.1, would it not make more sense
      to encode anyxml as a string? Right now, it is by definition 
      not interoperable.
  LL: But there are use cases where you have JSON that you want to
      exchange and the idea is to carry that in anyxml.
  MB: That really changes what anyxml is. It is clearly defined in
      RFC 6020.
  LL: There was no notion about JSON encodings when RFC 6020 was
      written and this explains it. If we do CBOR in the future,
      arbitrary CBOR will be transported in anyxml.
  MB: I am not sure that we can change the semantics of anyxml in
      this way.
  LL: We already represent YANG lists as JSON arrays.
  PS: The step from a YANG list to a JSON array is close to zero. I 
      do not think this justifies the new interpretation of anyxml.
  LL: Even if we decide that anyxml is any XML, we will have some
      technical problems to solve.

  JS: In YANG 1.1, we are adding anydata with the goal that encodings
      can transfer any YANG defined data in an interoperable
      way. Should this document not cover both YANG 1.0 and YANG 1.1
      and define how anydata is encoded? The goal is to have an
      interoperable solution that works with multiple encodings. The
      goal is not to have more non-interoperable encodings.
  LL: RESTCONF depends on JSON and it might be faster to publish this
      document based on YANG 1.0 and do an update later when YANG 1.1
      is done.
  AB: Nobody has ever demonstrated a server that supports arbitrary
      XML with anyxml. Why do we spent so much time on something that
      is not being used in an interoperable way? I think we should
      move on with something that is interoperable.

  JS: Should this document stay YANG 1.0 only or cover both YANG 1.0
      and 1.1?
  BC: We have several dependencies between the documents and it seems
      we need to publish several documents together.
  JS: My feeling is that we are relatively close with YANG 1.1 to have
      it in WG last call in May.
  MB: I agree that this is feasible. More reviews are welcome. I also
      support that we cover YANG 1.1 in the JSON document.

  The meeting supported to cover both YANG 1.0 and YANG 1.1 in the
  JSON document instead of doing this in two steps.

  LL: What about anyxml then?
  JS: We for sure need to have text that explains how to encode
      anydata in an interoperable way. This is of high priority. We
      will need to settle how to encode anyxml but this is then only
      for corner cases since the direction is that we do anydata in
      the future instead of anyxml.

** Actions

   - LL: revise the JSON document, adding support for YANG 1.1
   - JS: still need to settle the anyxml encoding issue

* Defining and Using Metadata with YANG

  LL presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-4.pdf

  JS: We had a call for adoption some time ago and the controversial
      comments were related to the examples in the document. I think
      the golden rule must be that metadata must be data that can be
      safely ignored. Anything that changes behavior is not metadata.
  LL: The document says that semantics of metadata are specified
      elsewhere, this is really just defining the syntax.
  PH: I assume that organizations will have their own way of carrying
      metadata.

  The meeting supported the adoption of this document.

** Actions

   - JS: another call for adoption to verify the support of the meeting

* AOB (YANG Language and Infrastructure)

  JS announces that he plans to step down as NETMOD co-chair when the
  YANG 1.1 work has been finished. People interested to become NETMOD
  co-chair should contact BC.

* Hackathon Notes

  BC reports about a tool created during the IETF 92 hackathon that
  extracts YANG modules out of IDs.

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-7.pdf

  TN: It is helpful if YANG authors read the guidelines document.

* SYSLOG Data Model

  CW presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-8.pdf

  No questions were asked.

* Entity-MIB Yang Model/Design Team Update

  TN explains that the design team was started just recently in order
  to provide a YANG data model covering physical components. The
  design team will meet later during the IETF 92 to discuss what needs
  to be covered and how things can be done in a way that is backwards
  compatible with existing SNMP instrumentation.

  BC: The background is that inventory proposals in the I2RS started
      to create data models that overlap with the ENTITY-MIB.
  SH: What is the timeframe of the design team?
  TN: The team will meet once per week and post an update once per
      month so ideally this is complete in a few months.

* Inventory Data Model

  JD presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-3.pdf

  SH: This started as a natural extension of the topology work in I2RS
      but falls somewhat outside the scope of I2RS and hence it got
      moved here.

* YANG Model Coordination

  BC described the recently started efforts for YANG data model
  coordination. He introduced the YANG model coordination team.  There
  are 113 YANG models in the IETF, YANG is used or considered to be
  used by several other SDOs, consortia, and open source projects.
  YANG training material is being created and work is underway for a
  YANG model repository. More details can be found on the OPSAWG
  meeting slides:

  http://www.ietf.org/proceedings/92/slides/slides-92-opsawg-2.pdf

* ACL Data Model

  DB presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-12.pdf

  JS: Is the ACE list ordered by user or not?
  DB: Our suggestion is ordered by user. But the system may sort them by
      number.
  JS: The order matters. If you use ordered by user, then numbers do
      not matter. Or the numbers matter, but then it is not ordered by
      user.
  PS: If they are ordered by user, the system can't sort them.
  PS: If you use ordered by user, then why not use names instead of
      numbers?
  DB: We wanted to use names, there was a comment to go back to sequence
      numbers.
  PS: I am against using numbers.
  JT: I want a way to allow both types of systems to support this module.
      Systems that use sequence numbers internally will have a hard time
      to support ordered by user. Perhaps the order can be augmented into
      the list. Operators will get confused if the order is not consistent
      with the numbers.
  PS: You can't augment an ordered-by statement.
  AL: An access list since beginning of time has been ordered by sequence
      number.
  PS: My implementation since the beginning of time as used names.
  JT: There is clearly a mix of implementations out there. Perhaps this
      can be made a feature?
  MB: You can't have an if-feature on the ordered-by statement. If the
      list is ordered-by user, you can easily map the position of each 
      list element internally to a sequence number.
  JS: A list can only be ordered in one way. We can decide about the
      order. Not sure what the alternatives would be, two lists?
  LL: We could have a choice with an if-feature.
  JS: How does the choice help?
  LL: The proposal is to have two separate lists in a choice.

  Three options:
    (1) two lists - 5 hands
    (2) sequence numbers / ordered by system - 2 hands
    (3) names / ordered by user - 7 hands

  AL: If you have the name as a tag, it will not be interoperable.
  DB: With sequence numbers, you will end up with renumberings, which
      is a performance problem.
  AL: Each access list will have a name. You want each ACE to have a name
      as well. If you do not have a sequence number, how does the system
      know where things go?
  PS: If you have names and you need numbers internally, simply use the
      position.
  MB: An ordered by user list means that the server has to maintain
      the order given by the client. This is interoperable across
      implementations.
  AC: Maybe the draft should explain better how this works if we go
      with a name for an ACE.
  JH: User ordered means that an ACE is inserted into a list based on
      how a user inserts it. The name (key) lets you refer to it but
      it is not used for ordering.

** Actions

   The draft needs to better document how ordered-by user works and
   can be implemented on systems that internally use sequence numbers.

* Core Routing Data Model

  LL presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-9.pdf

  PS: Have you considered to use features for modularizations instead of
      making things separate YANG models?
  LL: I think it is a better design pattern to have separate data model
      augmenting the proper choices.
  PS: Can an interface be in multiple routing instances?
  LL: This is an open issue, will talk about it later.
  AL: I think the main goal is to agree on the base hierarchy since
      several other models will depend on it.

  JH: Was the question of multiple routing protocol instances (e.g.,
      OSPF) brought up when routing instances were discussed?
  LL: You could have multiple routing protocol instances already
      before routing instances were discussed.

** Issue #1: instance vs. protocol-centric design

   LL: A poll of opinions on instance vs. protocol-centric design
       (slide 6) did not lead to a clear answer.
   PS: You should ask operators and vendors since vendors like their
       approach always most. That said, the routing-instance-centric
       approach has nice isolation properties.
   SL: The routing-protocol-centric approach has nice inheritance
       properties but we can emulate that with templates in the
       routing-instance-centric approach.
   SL: In terms of operational feedback, it seems people tend to 
       prefer whatever they are used to. That said, I lean towards
       the routing-instance-centric approach.
   LL: Yes, people seem to like what they are used to.
   AL: We did not reach consensus in the poll except that operators 
       want to have it done in one way.
   JH: Both models are perfectly fine for a single management plane.
       In multiple management plane, things become tricky. The
       routing-instance-centric approach nicely maps to a set of
       things, like the SNMP community string approach to distinguish
       multiple similar instances of things.
   CM: It would be interesting to hear from people who _program_
       things. The notion of templates is odd for most programmers
       but likely more useful for CLI users.
   LL: The template idea is a special type of routing instance that
       provides default information to other routing instances.
   CM: But one could easily argue that this template could also reside
       on the managing system, why do you want to waste storage on the
       router for storing templates?
   LL: I hope we will discuss templates soon on the routing
       coordination mailing list.
   AA: We are going to charter a routing area design team that will
       look at the routing data models and how to make them work
       together and to look at certain conventions to be used in
       routing data models.  The design team will also look at
       extensibility. I do not see this routing area design team
       directly impacting this model, it is more an orthogonal effort
       to this.
   LL: We have been trying to make the core routing model as extensible
       as possible. Sure, there are still some assumptions we make, but
       we try to be extensible where extensions can be reasonably be
       expected.
   AA: Yes, the routing area design team is more about documenting
       how to make YANG data models extensible.
   JS: Wonderful news. Is there a time line for the design team?
   AA: The goal is to get the metamodel (how things fit together) out
       by the next IETF. The other aspects may take more time. The
       reason this is routing centric is that we need to keep the
       work scoped.
   RS: We should not think about people typing into the CLI, the goal
       here is programmability. So we need to think about the operation
       that people want to automate. From this perspective, the
       routing-instance-centric model seems to make more sense to me.
   LL: I believe mappings between the two models are possible.
   RS: We should push this forward in order to get experience with it.
   AL: I have looked into mappings of both directions and they seem to
       be possible. It may be easier to map from a
       routing-instance-centric model to a routing-protocol-centric
       backend than from an routing-instance-centric backend to a
       routing-protocol-centric model.

   The meeting room showed a very strong and clear preference for the
   routing-instance-centric model (many in favor, nobody in favor of
   the routing-protocol-centric model).

** Issue #2: RIB Placement

   LL: Current proposal is to move back to have RIBs per routing
       instance instead of global RIBs.
   SL: Global RIBs do not make sense to me. You can't share a RIB
       between routing instances.

   Nobody was speaking up in favor of global RIBs, hence this will be
   changed back to have RIBs per routing-instance.

** Issue #3: RIB Connections

   AL: There should be a feature to have multiple RIBs per address
       family to support multi-topology routing that some platforms
       support. The RIB should be contained in a routing instance and
       as a feature there could be multiple RIBs per address family.
   LL: This is not only a Juniper feature, the Bird routing daemon
       has something similar.
   JH: I am happy to have RIB connections removed. Routing protocols
       interact with RIBs and RIB groups could be modeled as a logical
       entity that passes information between RIBs.
   LL: I am OK with removing this from the core model because this can
       be added via augmentations.

   Nobody was speaking up against removing RIB connections from the
   core routing data model.

** Issue #4: Interface Assignment

   JZ: Assignment to routing instances not only makes sense for IP layer
       interfaces.
   JZ: I could see that an IPv4 interface belongs to one routing
       instance and an IPv6 interface belongs to a different routing
       instance.
   LL: For some interfaces, it does not make sense to assign them to
       any routing instance.
   JZ: There are already IPv4 and IPv6 specific containers for IP
       interfaces (RFC 7277). They could be reused to scope things.
   AL: This may be a better place to point to. Anyway, if we do have
       two IP layer lists, we need guidance which one augmentations
       should augment.

   Further discussion on the mailing list is needed.

** Issue #5: IPv6 RA Parameters

   AL: If we did not have RFC 7277, I would agree it does not make
       a difference. But since we already have RFC 7277, we should
       augment ip:ipv6.

   Further discussion on the mailing list is needed.

** Remarks

   BC: Since this core data model is very important, we may want to
       wait with publication until at least one routing protocol
       specific data model is done as well. Ideally, we would even
       have some implementation experience before we publish this as
       an RFC.
   LL: I agree that we need to get this right and once published as
       RFC it will be way more difficult to make changes.

* Data Model Classification

  DB presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-13.pdf

  MJ: I agree with CM that two levels are sufficient.
  MJ: Proprietary extension to a standard model is just a proprietary
      model, I do not see the difference you are making.
  DB: An example is a match condition augmented into a standard model.
  BC: The SYSLOG data model will focus on common features and vendors
      will augment the standard data model with their specific
      extensions.
  RS: I do not care so much how many layers there are. What matters
      is the abstraction between the layers. And this also relates how
      operators are internally organized.
  JH: There is a need for common names for knobs that are proprietary
      but supported by multiple vendors.
  ??: Business model, service model etc. should be covered by an
      information model.  Component models should be covered by a data
      model. We need an information model architecture in
      addition to a data model architecture.
  JH: The high-level architecture does not get specific to the point
      that it prescribes implementation.  That should probably be
      clearer in the slides.
  KS: There should be some abstraction between service model and the
      element model. The Service Model should be neutral. Perhaps
      that's what you mean by the YANG model.
  DB: I can create a service model solely using proprietary YANG models.
  KS: But this is going to be very hard for us to map.
  DB: You have a choice how the service model is created.
  KS: We also need some neutral model in the middle. It has to be
      instantiated also outside of the element, e.g. a controller.
  DB: You have to know what your devices do support.
  KS: But there are always some devices that support things and other
      devices that do not support things.
  CM: You are far ahead of us. The decomposition is still open to be
      worked on. I agree this is not in scope what we are doing now
      and it is something we will have to take on.
  EO: The idea of the IETF defining a service makes me nervous. The
      fact that the IETF does not define service is a feature.
  DB: We are not saying the IETF is going to define services. All we
      try to come up with a taxonomy that works ideally across SDOs.
  EO: As long as this does not lead to a proliferation of service
      models, I am fine. We need to avoid feature creep.
  BC: Service models in the IETF are an open question. We could do a
      design team in the IETF to do this. We did this for L3VPN.  We
      have a new WG approved on Monday.  I don't believe we should
      have all services, but this one, yes.
  AC: You have multiple dimensions and it makes sense to distinguish
      them. Whether something is proprietary or standardized crosses
      the layering hierarchy.
  DB: This means splitting the orchestrator box also into two parts.

  RS: The value of the L3 service model is (a) that we figure out
      whether all service level knobs actually map to something in the
      element models and (b) the decomposition work itself.
      Identifying the primitives used to build services is useful.
  EO: Primitives are great but we do not want to market RFC XYZ 
      services.
  PS: There is a motivation between vendors and operators to have open
      standards that drive tools to automate interaction with equipment.
      What is the motivation for service modeling?
  DB: We just want to define a taxonomy.

  Further discussion on the mailing list is needed.

* Consistent Modeling of Operational State Data

  AS presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-10.pdf

  DB: If we adopt any of this, we should fold that into the RFC 6087
      update.
  TN: You also talked about changes for NETCONF.
  NS: Is this a way to do better error handling, e.g., errors due to
      a (transient) lack of resources?
  AS: You can observe state data based on which you can decide what to
      configure next. There is difference here between synchronous
      transaction driven systems and asynchronous systems.
  EV: Have you though about synchronization across multiple devices?
  AS: Not really, we have so far focused on a single device.
  PS: Why not use an operational state datastore? This seems pretty
      simple, no?
  AS: We have not thought much about this. Having things marked up in
      the data model has advantages. It is not clear having an
      operational state data store is sufficient.
  BC: Thanks for sharing experience. What about existing RFCs? Do you
      ask to change them?
  RS: This is just a strawman. There is the question about datastores
      and does the protocol have proper support to access separate
      datastores.
  TN: There are models in published RFCs. Does this affect them?
  AS: We need some common convention for operational state.
  JS: For the data models produced by the WG, we actually paid quite
      some attention to operational state. This may not be as visible
      from the drafts but quite some discussion of operational state
      has gone into the design of say the interface data model. If
      there is a better way, it needs to be significantly better to
      justify the costs of changing data models published as RFCs.
  AS: The problem may be more for work in development rather than
      published models. That said, if you put models together, you
      get a tree that looks somewhat suboptimal.
  CM: It will be useful to have a programmer's view here. If things
      are asynchronous, then you also need notifications.
  AS: Yes, we have to move towards a continuous streaming model for
      incremental updates.
  JH: Structural separation is a good thing. I was hoping for a 
      request for NETCONF to define a get-op-state as an alternative
      to the get operation.
  AS: Yes, this would be nice to have, but it would be nice to have 
      a distinction in the data model.
  JH: For the data models, you likely want foreign keys that make it
      easy to correlate information.
  BL: Finding state data for a specific configuration item is a
      problem for us as well.
  ??: Have you implemented your proposal? There are performance impacts.
  AS: The content of the different subtrees or the different datastores
      is different. We have implemented it on the consumption side, but
      not on the devices yet.
  ??: For us, this seems costly to support.
  EV: There is a pub/sub requirements document in I2RS.
  SL: For routing protocols, we augment the core routing data model and
      we will not have many nodes at the top-level.
  AS: But this works if there is a suitable model in place already.
  AS: We came to the conclusion that the split between config and
      operational state data is either done at the beginning of the
      path or the end. This raises the question what is the beginning
      of the path.

  Further discussion on the mailing list is needed.

* Operational Structure and Organization of YANG Models

  RS presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-11.pdf

  DB: Why do you not intend to be extensible?
  RS: We do try to be extensible, we do not try to be exhaustive.
  AB: Where the data lives in the tree is almost irrelevant. We need
      an outside classification instead of trying to encode semantics
      into the tree.

  Further discussion on the mailing list is needed.

* Diffserv Data Model

  MJ presented his slides:

  http://tools.ietf.org/agenda/92/slides/slides-92-netmod-2.pdf

  Further discussion on the mailing list is needed.

* Peer Mount Requirements

  Canceled - meeting did run out of time.

* AOB (Data Modeling)

  Canceled - meeting did run out of time.