Minutes for NETMOD at IETF-87
minutes-87-netmod-1

=============================================================
NETCONF Data Modeling Language WG (netmod)
IETF #87, Berlin, Germany
Thursday, August 1st, 2013, 17:00-18:30, Tiergarten 1/2
Minutes Nikolay Melnikov, Juergen Schoenwaelder
=============================================================

WG Chairs:      David Kessens <david.kessens@gmail.com>
                Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
WG URL:         http://tools.ietf.org/wg/netmod/
Jabber:         xmpp:netmod@jabber.ietf.org

Agenda:

 1) Administrivia (chairs)                                      [ 5 min]
          
    - minutes scribe     {volunteers welcome in advance!}
    - jabber scribe      {volunteers welcome in advance!}
    - blue sheets
    - agenda bashing
    - status and milestones

 2) Core interface data model (Martin)                          [10 min]

    - draft-ietf-netmod-iana-if-type-07   (WG last call until 2013-07-22)
    - draft-ietf-netmod-interfaces-cfg-12 (WG last call until 2013-07-22)
    - draft-ietf-netmod-ip-cfg-09         (I-D update pending)
          
 3) Core routing data model (Martin, Ladislav)                  [15 min]

    - draft-ietf-netmod-iana-afn-safi-00
    - draft-ietf-netmod-routing-cfg-10
          
 4) Core system data model (Andy)                               [10 min]

    - draft-ietf-netmod-iana-timezones-00 (WG last call until 2013-07-22)
    - draft-ietf-netmod-system-mgmt-08    (WG last call until 2013-07-22)

 5) SNMP configuration data model (Juergen)                     [15 min]

    - draft-ietf-netmod-snmp-cfg-02       (I-D update pending)

 6) YANG data model for network topology (Jan)                  [15 min]
          
    - draft-clemm-netmod-yang-network-topo-00

Summary:

  The NETMOD working group has met for 1.5 hours on Thursday, August
  1st, during the 87th IETF meeting. The meeting was attended by ~50
  people.

  * Several documents are in WG last call and more reviews are needed.
    Some additional people were recruited during the meeting to perform
    reviews.

  * The routing documents are technically complete. Lada will work with
    authors of the I2RS working group to harmonize things with the
    information model defined by the I2RS working group but this must be
    completed the latest by the next IETF meeting in Vancouver; the
    NETMOD WG is not going to wait for the I2RS WG to complete its work.

  * Some minor issues need to be resolved on the SNMP configuration
    model. The next revision is expected to be complete and ready for WG
    last call.

  * A new individual draft was presented and discussed which defines a
    generic data model for presenting network topologies. This I-D is
    related to an information model submission to the I2RS WG.

  * The open mike discussion centered around the future role of the WG,
    if it is time to move data model work out of NETMOD into other
    working groups, how to provide guidelines to data model writers, and
    whether the YANG specification should be revised to make it less
    dependent on NETCONF concepts and whether new features should be
    added the YANG.

Actors:

  - JS = Juergen Schoenwaelder
  - AB = Andy Bierman
  - MB = Martin Bjorklund (via Jabber)
  - LL = Ladislav Lhotka
  - DK = David Kessens
  - BC = Benoit Claise
  - KW = Kent Watsen
  - BL = Balazs Lengyel
  - BW = Bert Wijnen
  - DL = David Lamparter
  - JM = Jan Medved
  - DB = Dean Bogdanovic
  - AM = Adam Montville
  - JH = Jeff Haas
  - LF = Luyuan Fang
  - DW = David Waltermire (?)
  - DH = David Harrington

Slides:

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

Audio:

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

Meeting Notes (focusing on the open issues discussed):

* WG status and milestones

  - BC states that it is good to see more and more YANG modules.
    However, more reviews are needed for existing chartered work in
    order to be able to finish it. Chris Elliott has volunteered to
    review NETMOD documents as well as Susan Hares. Authors of new
    drafts should also help to finish up existing chartered work since
    this will help their proposed work as well.

  - AB states that two of drafts in WG last call are just large YANG
    translations of IANA registries that no one cares about, since
    they were not touched in months. People lose interest in reviewing
    micro-incremental edits for many times. I checked the diffs. I
    have no comments and no objections. These drafts had a lot of
    reviews. Maybe we need to bring in more outsiders for more
    reviews.

  - DK states that complete silence during WG last call is scary, but
    saying something short and confirming is helpful.

  - BW offered to review the documents if he gets two weeks to do
    this.

* Core interface data model

  - No comments were raised on these documents, no slides, no
    presentation.

* Core routing data model

  http://www.ietf.org/proceedings/87/slides/slides-87-netmod-2.pdf

  - LL implemented the separation of operational state from
    configuration state following the interfaces data mode. However,
    YANG leafrefs cannot refer to config false nodes - this may
    require to create dummy configuration entries. LL considers this a
    crappy little rule (CLR).

  - AB states that the decision to have config true/false (even though
    perhaps not the correct design decision) is essential for NETCONF
    implementations and not just a CLR.

  - LL asks why do I have to create a dummy configuration entry?

  - AB explains that the configuration datastore is really distinct
    from operational state and hence must be complete and can only be
    further constrained by other configuration. AB believes this was a
    good decision.

  - LL says we just refer to a name, and if the system can find it,
    then it should be okay.

  - BL mentions that there was an instance required modifier proposal
    that could have solved this.

  - AB but this never made it into YANG. We also had originally three
    states (transient configuration) but this was taken out. These
    rules can't be easily changed and require to revise the YANG
    specification.

  - DL suggests to perhaps add another kind of reference that is
    treated a bit differently.

  - BL states that this is what he believes instance required was.

  - AB explains that the reason for this rule is to allow off-line
    validation.

  - LL suggests to discuss this further on the mailing list.

  - LL suggests that there is an inconsistency with the guidelines
    document (section 4.9 of RFC 6087) since we now move towards a
    design pattern with multiple top-level containers.

  - AB says that we need to consider updating the guidelines.

  - JS asks the question how we deal with the relationship to the
    routing information model developed by the I2RS working group.  It
    would be nice to have consistency here. Shall we move ahead with
    what we have or shall we wait until the I2RS work becomes stable
    or something in between?

  - LL I think we should go ahead, as I2RS is just forming information
    models, so it will take them a few years, and we cannot wait for
    that long. Maybe we could change something later in this data
    model, but we have to do it anyway.

  - JM (co-author of the information model draft submitted to I2RS)
    has met with LL in order to find out where any differences are.
    There are lots of unknowns about the differences at this point in
    time. We need to compare item by item what the deltas are.

  - LL says that this likely can be done until the next IETF.

  - DK asks whether there is a reason why we have to wait for the next
    IETF? Can this be done earlier, using the mailing list?

  - JM says sure we can do that as well as the work proceeds.

  - BC says that I2RS milestone for the information model document is
    February 2014. Do you think it is feasible, and what is your
    plan. How long should we be waiting. I am in favor of being in
    sync (with I2RS).

  - JM says that February 2014 may still be feasible.

  - JS suggests that the maximum timeout for the delta analysis should
    be the Vancouver IETF.

  - LL expects to post a revised I-D of the routing data model before
    the Vancouver meeting.
    
* Core system data model

  http://www.ietf.org/proceedings/87/slides/slides-87-netmod-0.pdf

  - AB reviews the changes and asks for more reviews.

  - DK believes that the changes to this draft were much more
    incremental compared to the interfaces draft.

  - AB agrees and repeats his suggestion that the WG may need to
    update the guidelines document (RFC 6087) at some point in time to
    reflect the current practice.

* SNMP configuration data model

  http://www.ietf.org/proceedings/87/slides/slides-87-netmod-4.pdf

  - JS expects the next revision of the I-D to be complete from the
    author's point of view.

* YANG data model for network topology

  http://www.ietf.org/proceedings/87/slides/slides-87-netmod-3.pdf

  - JM presents the basic concepts of the topology data model.

  - BL asks unidirectional point-to-point links were chosen to the
    topology.

  - JM responds that the idea was taken from l3 protocols. They
    represent topologies via unidirectional links and it turns out to
    be a very generic way of representing topologies. Links can have
    very different attributes in each direction.

  - BL raises some questions concerning broadcast links.

  - JM suggests to take this to the list and to work this out with
    routing experts.

  - DL is the purpose of this to report operational state about the
    current topology north-bound? If so, why is everything read-write?

  - JM yes and you raise a good point. 

  - MB asks why did you model this as configuration data?

  - JM responds that this should be config false (read-only) data.

  - BL says that there are sometimes internal interfaces that are only
    connected to some of the nodes. There should be a way to represent
    how interfaces are interconnected.

  - JM we represent abstract nodes (or topology nodes), not
    necessarily real interfaces.

  - BL says that there should be a clarification how this mapping to
    real interfaces works.

  - JS asks how many people have read the document. About 5 people
    plus some unclear signs.

  - JM we hope to further develop this until Vancouver.

  - DL suggests to add some examples.

  - JM agrees and this comment was also raised in the I2RS working
    group.

* Open mike

  - LL says that YANG is being used in other places but not
    specifically in combination with NETCONF. Several definitions in
    the YANG specification make use of NETCONF concepts. Should this
    WG review the YANG specification to make it less dependent on
    NETCONF?

  - DB supports this view as it will help using YANG for other
    purposes.

  - AB says that changing YANG needs to be done very carefully.  It
    may be too early to do this and it seems YANG can already today be
    adopted to other protocols using extensions. Applying YANG to
    YANG-API / RESTCONF is mostly straight-forward as long as we talk
    about data nodes.

  - JM supports LLs suggestion. There also was an I2RS document
    detailing YANG extensions that would be likely needed. YANG is
    also being adopted by the open daylight project and we have tools
    to produce code withing a system that need extensions of YANG.

  - AM says that the SACM working group is looking at YANG and they
    might use YANG for network access control. I support YANG being
    more NETCONF independent.

  - AB sees YANG data models being submitted but how do we deal with
    them? Do we move the data models to other working groups while the
    NETMOD working group focuses on the maintenance of the YANG
    language? AB likes to see proposals being worked on.

  - ?? supports to move the writing of YANG data models to other
    working groups while NETMOD should focus on the maintenance of the
    YANG language.

  - JH says that this WG is becoming a victim of success and you have
    to maintain YANG. While moving work to other working groups, be
    aware that this working needs to help them getting the data
    modeling right.

  - MB agrees to the idea of revisiting YANG and that it makes sense
    to move data modeling work to other working groups. Maintenance of
    YANG should be done in NETMOD.

  - AB says that in the MIB development space, we achieved good
    results when we got language and modeling experts work together
    with domain experts.

  - AM says working together would be wonderful if this can be made to
    work.

  - LF asks whether we can agree that work on YANG belongs to this WG
    while work on subject specific data models belongs to other
    working groups but then to be reviewed here?

  - DK sees a consensus developing into that direction, but he is not
    sure there is agreement on the time-line. Might need input from
    the area directors.

  - LL observes that for some work items there are no working groups
    (e.g., route filters or stateless packet filters).

  - DW is working in the SACM working group and he finds good guidance
    on how to use YANG very useful.

  - BC is happy to see technology used in multiple WGs. We may need to
    provide guidance but there are also documents that do not have a
    home. It is unclear how we ensure that documents using YANG get
    sufficient review and yang-doctors may not be enough.

  - DK as a contributor believes it is likely too early to make a
    decision since people need to develop more expertise. As WG
    co-chair, do we need to make decisions about this today or is this
    more an informal discussion that will come up at the next IETF.

  - JM states that YANG is not yet decided by the I2RS working group.
    He considers this discussion an informal discussion to be
    continued.

  - LF sees two level of reviews. Expertise by the subject matter
    experts and a review beyond the language itself to ensure
    higher-level consistency beyond the language itself.

  - DH says that this area of the IETF has experience with organizing
    reviews. It is not this WG's decision what other WGs do or not. It
    is important to review WG charters and to provide input to the
    Area Directors (BC in this case) to influence how the IESG
    approves charters. While there are YANG guidelines, what is
    missing are guidelines how to design data models properly.  RFC
    5706 may be reviewed and perhaps some of its content applies to
    designer of YANG data models.

  - BC prefers to have information models in WG charters instead of
    data models. Design guidelines are clearly useful to have, in
    particular also with a view of code generation.

  - DB believes we should have a better understanding of how to
    decouple YANG from NETCONF so that we can take an informed
    decision in Vancouver.

  - BL says that there have been new requirements on YANG. Is there
    anything we do about them?

  - LF believes that the scope of YANG data models is bigger than what
    we did in the past with MIB modules. Concerning timing, we should
    discuss but decide better sooner than later.

  - LL believes that there a number of bugs or enhancements for YANG
    but we need to be very careful that we do not start boiling the
    ocean or rehash discussions we had before.

  - KW believes that maintaining and enhancing YANG should be the
    primary activity of this working group. KW is in favor of opening
    the YANG specification and adding new capabilities to YANG.

  - DH disagrees with KW. What is needed are more data models.
    Operators said at the IAB workshop that one reason to not use SNMP
    is that data models are incomplete. It is also important to not
    send the signal that YANG is unstable to the industry.

  - KW says that Juniper is interested in YANG for JunOS, but it is
    not fully able to express what Juniper needs. We are working
    around this with proprietary extensions.

  - MB says if we revise YANG (RFC 6020), we need to concentrate on
    things that cannot be done with YANG extensions.