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

=============================================================
NETCONF Data Modeling Language WG (netmod)
IETF #89, London, United Kingdom
Wednesday, March 5th, 2014, 13:00-15:00, Palace C
Minutes Balazs Lengyel, Juergen Schoenwaelder
=============================================================

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

Agenda:

  1.  Administrivia and WG Status (Juergen & Thomas)      13:00 [ 5 min]
  2.  Recharter Discussion (Thomas & Juergen)             13:05 [20 min]
  3.  YANG Maintenance Issues (Martin)                    13:25 [60 min]
  4.  YANG Conformance (Andy)                             14:25 [10 min]
  5.  YANG Guidelines (Andy)                              14:35 [10 min]
  6.  Stateless Packet Filter Config Data Model (Andy)    14:45 [10 min]
  7.  Open Mike                                           14:55 [ 5 min]

Summary:

  The NETMOD meeting in London was attended by about 70 people. All
  currently charter work items are either in the RFC editor queue, on
  the IESG agenda, or they passed WG last call and are on the way to the
  area director. The discussion of a proposed new WG charter resulted in
  some minor modifications. The WG also discussed the ecosystem around
  YANG data model development and support and how it could be improved
  to better support and accelerate implementations of YANG modules. The
  active contributors indicated support for the new charter and there
  were no objections. The revised charter text including the
  modifications has been circulated on the mailing list right after the
  meeting. After the charter discussion, the WG started to go through a
  list of issues that may be addressed in a YANG maintenance release in
  order to determine which issues are in scope, out of scope, or need
  more discussion. The status of the stateless packet filter data model
  and a revision of the guidelines document has been reported.

Slides:

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

Audio:

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

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
  - JM = Jan Medved
  - QZ = Quintin Zhao (??)
  - MA = Mikael Abrahamsson
  - RV = Robert Varga
  - DB = Dan Bogdanowich
  - DY = Derek Yeung
  - AK = Anik Kachik (??)
  - SC = Steve Cheng

Meeting Notes:

* Rechartering Discussion

  BC: If there are YANG modules that are not part of a charter of an
      active working group, they are welcome in NETMOD.
  JS: What about situations where we have an active WG but YANG work
      is not on the charter?
  BC: We will talk with the ADs and WG chairs to sort this out (like
      we did in the I2RS case).
  BC: Expert review is key and required.
  AB: Our process is lacking the use of issue trackers. We get many 
      late reviews and issues pop up again.

  ??: The PCE working group is currently doing MIB modules and the
      policy is to finish this work before considering YANG modules.
      As an implementer, should I wait for this process to finish or
      should I go to NETMOD in order to make progress?
  BC: I will discuss this with the ADs and WG chairs involved.

  MA: How is the whole ecosystem going to work? Which models are
      needed? We need hundreds of models to configure everything using
      NETCONF and YANG. I am concerned about the whole process and the
      ecosystem. Perhaps you want the YANG models be developed
      alongside the standard. Perhaps you want a well-known repository
      during development, a more decentralized process may be needed.
  AB: The hard part of doing a standard is reaching consensus among
      competitors.
  MA: A community process could prepare YANG modules for a later RFC
      approval process.
  RV: Keeping models close to implementation is critical during
      development. We may need an upstream/downstream model where
      things are prototyped and then pushed upstream into the IETF
      process. For example, start with simple draft with basic
      concepts, let people implement and build on it, then add more
      features.
  MA: What I want to avoid having multiple vendors each creating their
      own model and to merge them late in the process. Trying to seek
      early agreement is much better.
  JM: There are a couple of foundational models, topology is one of
      them and another one is inventory. Since these models are
      foundational, it may be a good idea to develop them in this
      working group.
  BC: I do not have the solution: The IETF is about running code and
      consensus. We need to find the balance between the two.
  LL: It is not likely that this working group can do all data models.
      There is an OSPF module which is quite Cisco specific. I have
      one that is Bird specific. It is up to the vendors to work out a
      common model. Experience with the routing module tells us that
      the exposition to routing experts is much less here than in the
      routing area. Leave it to the domain experts to do their data
      models. We can help them but not do their work.
  DB: Agrees that this WG should help if there are specific questions
      coming up in other working groups.
  MA: My proposal was not to move all work here but instead help others
      to find good workflows.
  RV: I agree. Need guidelines how to solve certain problems with YANG.
  DY: Some help is needed how to represent things correctly. We can
      work with the experts in other working groups to sort out what
      should be standardized and what not.
  AB: We have a process called design teams. I do not see this is any
      different, we could simply work with design teams creating
      vendor neutral models.
  ??: L2VPN (co-chair) It might make a difference whether the model
      lives on a network element on in some kind of a controller.
  MA: This group should aid others with their YANG module development.
  BC: YANG Doctors are there for helping others.

  KW: Maybe we could compile a list of new concepts and review it?
  MB: How do we actually define new data modeling concept? Maybe this
      text is OK and we need to define on a case-by-case basis.
  RV: Is introducing a new base datatype (floats) considered a new 
      data modeling concept?
  DB: Change to a should not add new data modeling concepts?
  JS: The motivation behind the text and in particular the third
      bullet was to keep YANG stable and to avoid sending out a
      signal that YANG may change significantly (e.g., becoming
      object-oriented to name an example).
  BL: Is this language enough for I2RS in order to use YANG?
  JM: If I2RS picks up YANG, do we recharter again to meet their
      needs?
  TN: We want to support I2RS and RESTCONF but not go beyond.
  BC: We need to resolve how we deal with ephemeral state, either
      in NETMOD or NETCONF.
  MB: As far as we know right now, everything I2RS needs can be done
      with YANG extensions. The goal of YANG 1.1 is to open it up in a
      few cases such that the language does not need further changes.
  LL: Some formulations in RFC 6020 are NETCONF specific. We should try
      to make things more protocol neutral.
  JS: The goal is that YANG 1.1 reaches a point such that groups like
      I2RS can get everything done with extensions, that is without
      changes to the YANG core.
  KW: The text says NETCONF but it should probably also mention
      RESTCONF.

  JM: I see stateless packet filter work but no other data models. As
      mentioned before, I consider other foundational data models.
  JS: My understanding was that the topology work was moved to I2RS.
  JM: Because this working group did not pick it.
  BC: Need to check my emails but I think this was discussed with the
      routing ADs and the WG chairs.
  MB: The charter is open to take on additional data models.
  JM: I think topology and inventory should be done here.
  JS: I am concerned about an information model in I2RS and a data
      model in NETMOD. I think they belong together.
  JM: I2RS started only doing information models.
  RV: There are a number of information models that really are basically
      nodes and arcs.
  JM: We already have tools in place that transform data models into 
      running code. Information models are somewhat nebulous.
  TN: The routing ADs confirmed that I2RS would work on topology data
      models but perhaps we need to have this discussion again.
  DB: The charter text should support both NETCONF and RESTCONF and
      not be NETCONF protocol specific.
  BC: What about YANG tree diagrams, which came up during IESG
      review?
  JS: This may become part of the guidelines or a separate document if
      people think this is useful but some people might find the cut
      and paste text fine as well since the description of the format
      is right in place.
  TN: Is the scope of the work appropriate?
      About 20% of the people in the room in favor, nobody against.
  AB: I did not see the YANG conformance work anymore, has this been
      dropped?
  JS: It is part of YANG 1.1. We will go through a process collecting
      all YANG 1.1 issue and then determine one-by-one what is in scope
      of the YANG 1.1 document.
  
* YANG Maintenance Issues

  - boolean if-feature expressions

    AB: There may be other solutions, e.g., by using xpath.
    MB: No, xpath only works in must and when statements.
    KW: This is a real-world issue.

  - allow must in input and output statements

    BL: It is unclear what must in an output means.
    MB: You can already do that within containers in output statements.

  - accessible tree in xpath in notifs and rpc

    AB: Servers ignore the constraints on their output. It is the
        clients that do the validation but they do not have access to
        all the state data.
    AB: I do not think this is problem worth solving but in any case
        we should make sure the solution is implementable.
    RV: I confirm that this is difficult or impossible to do.

    AB: A mandatory true statement in rpc output indicates that a server
        implementing a non-mandatory leaf never returns it. But this
	may be a separate issue.

  - unprefixed path in top-level typedef

    <no discussion>

  - escaped characters in double quoted strings

    <no discussion>

  - do not allow when on keys

    <no discussion>

  - make leaf-list of type empty illegal

    <no discussion>

  - allow optional keys?

    LL: What does this mean? Keys are not mandatory?
    MB: Some key elements may be absent.
    MB: There still must be a unique value to identify a list element.
    ??: If you have two optional keys, then one key must be present.

  - allow restrictions on enumerations

    <no discussion>

  - allow if-feature on enums?

    KW: We also need a way to say NOT feature. This is useful
    AB: I am concerned that this makes implementations really
        complicated. I am not sure this is really helpful since
	this is part of the leaf validation code.
    MB: I do not see why this is more complex than must expressions.
    KW: I have a cluster use case, having feature constraints
        specified for enums is helpful.

  - initialized-by server

    <no discussion>

  - allow multiple 'base' stmts for identities

    AB: Why is this needed?
    LL: Sometimes you have an identity that is a combination of two
        identities.
    LL: Identities should be a partial ordering, currently base values
        are excluded.
    RV: This is useful when identities are used to capture multiple
        inheritance hierarchies (e.g., mapping to Java interfaces)
    JS: It might help to have clear use cases for this.

  - clarify the string value for identities when used in must/when

    <no discussion>

  - identity advertisement problem

    RV: This can be solved by providing guidance to module
        organization, move identities to separate modules.
    AB: Identities are just identifiers and I do not see the need for
        multiple bases. We seem to be trying to overload identities.
    LL: The way identities are used in core modules (when expressions
        in an identity), you want to include all identities derived
	from a certain base.
    AK: We use identities to represent service types in open daylight.
        We are modeling how other parts of the data model are structured
	using identities.
    RV: Using YANG extensions, I can attach semantic meaning to
        identities and hence separating identities into separate
        modules is important.
    AB: Make sure we expand the usage of identities carefully. And we
        either partition models into multiple modules or we have more
        powerful conformance mechanisms. Full module conformance has
        already proved inadequate.
    RV: Refining identityrefs is full of holes.
    MB: Please bring this to the list so we can take a look.

  - module advertisement optimization

    RV: Yes, definitely a problem, in particular for implementations
        that work with size limited static buffers.

  - remove import-by-revision?

    AK: Import-by-revision helps with debugging and its usage should
        probably be mandatory.
    MB: But this is not incompatible if types are added. YANG rules
        protect you.
    AK: But it is fine to pick the latest version.
    RV: AK, you are referring to a minimum revision of a module.
    MB: Yes, this is not how it works today.
    AB: If you follow the update rules and the server advertises the
        latest version, everything just works.

  - support recursive groupings?

    KW: A use case is topology but there should be data model defined
        limit.
    MB: But this depends on the way you model topology. You can model
        topology without needed recursion.
    LL: In my view it was a design decision to avoid recursive structures
        in the data tree. Use leafref's to handle such situations.
    MB: Using leafrefs may not always been very natural.
    BL: I have seen use cases like modeling hardware containment or
        nested queues in quality of service models.
    RV: Please don't, you can avoid it and it adds a lot of complexity.

  - remove auto-assignment of enum values?

    LL: I do not buy the backwards compatibility argument since the
        number assigned to an enum is never exposed anywhere in
        NETCONF or YANG. The automatic assignment should be removed.
    MB: If the tools are using the assigned numbers, then the tool
        produces inconsistent results.
    LL: But this is all local to an implementation. If there is meaning
        of the numeric value, it should be explicitly assigned.

* YANG Conformance

  AB reviewed the recent changes and he discussed the next steps.

  MB: Caching the entire capability set is problematic since it
      requires an update of the NETCONF protocol. Caching of just the
      data model announces should be doable.
  AB: I agree and the number of NETCONF protocol capabilities is small.

* YANG Guidelines

  AB reviewed the upgrades of the guidelines and the open issues.

  RV: I think the definition of the tree diagram format should be in a
      separate document and I tree diagrams should be non-normative.
  AB: I like this approach.
  MB: We will have to keep working on this document until we have YANG
      1.1 done.
  AB: We also need to look for things that are legal in YANG but not
      allowed in IETF modules.
  JS: People who recently learned using YANG should provide feedback
      what is missing or could be improved.
  AB: One task of YANG doctors is to inform people that they ignore
      existing work.

* Stateless Packet Filter Config Data Model

  The document has not changed. AB explains that this document aims at
  establishing a framework, not to be covering all possible filters.
  This is a core model but it won't have all possible filters in it.

  JS: Clearly this document needs more review in order turn this into
      a framework that can be extended without touching the framework.
  AB: This is an example showing that going from a vendor specific
      module to a standard is difficult.

* Open Mike

  DY: The OSPF data model has been updated. We are looking for a YANG
      doctor to help with this module. We will take this to the OSPF
      working group be we need help to get the YANG aspects right.
  KW: Juniper has the notion of a default configuration. I will take
      this to the list.
  SC: Do you consider some QoS YANG modules?
  JS: It all depends on having concrete proposals (Internet-Drafts)
      that we can look at and form an opinion.