Skip to main content

Minutes IETF103: netmod
minutes-103-netmod-03

Meeting Minutes Network Modeling (netmod) WG
Date and time 2018-11-08 09:10
Title Minutes IETF103: netmod
State Active
Other versions plain text
Last updated 2018-12-05

minutes-103-netmod-03
Key Decisions (by draft)
========================

  draft-ietf-netmod-yang-data-ext-01

     - issue 1 move forward with the proposal on the slide
     - issue 2 proposal on slide  (rob will comment on list)
     - confirm on list

  draft-lengyel-netmod-yang-instance-data-05

     - move detailed use cases to appendix.

  draft-kwatsen-netmod-artwork-folding-08

     - source code begin / end code to be confirmed on list

  draft-ietf-netmod-nmda-diff-00

     - Milestone try to do the optimal (come up with the best format) as
     opposed to
      just using yang patch, and have one format from the outset. (targeted at
      104)

  draft-wu-netmod-factory-default-01

     - Poll for adoption as a WG item

  draft-ietf-netmod-module-tags-03

     - Additional last call not required / confirm on list
     - Requested addition of an example

  draft-verdt-netmod-yang-versioning-reqs-01

     - Poll for adoption after best effort at a description of the requirements

  draft-verdt-netmod-yang-solutions-00

     - Lou writeup for Modified-Semver

Minutes
=======

Session 1
TUESDAY, November 6, 2018
0900-1100  Morning Session I
Chitlada 2

Recording
https://www.youtube.com/watch?v=TQrHqpvkC90

#   Start      Time  Information
1   9:00  10  Title:  Intro, Charter & WG Status
              Presenter:  Chairs
              Draft:  N/A

2   9:10  10  Title:  Common Interface Extension YANG Data Models,
Sub-interface VLAN YANG Data Models
              Presenter:  Rob Wilton?
              Draft: 
              https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-06
              https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-04

Lou Berger - We talked about formalizing the liaison with the IEEE - should we
do that? Rob Wilton - Informal is fine with 802.1. Lou - You participate in the
coordination meetings so you'll bring that up? Rob - Yes at various stages Rob
- draft-ietf-netmod-intf-ext-yang is ready for last call Lou - Has the l2 vpn
draft been raised with the bess group? Rob - IEEE is happy with current status.

> 3   9:20  10  Title:  YANG Data Extensions
>               Presenter:  Kent Watsen
>               Draft: 
https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-01

Kent Watsen -
Issue 1
        We move forward with structure like on the slide
        (no objection)
Issue 2
        proposal is a large diverge from the main data structure requires
        updates to the zero touch model

Rob - Does this make it not so nice to read?

Kent - The instance document you get is probably identical.

Lou - You can can augment the structure where before you could only augment the
instance.

Kent - Certainly with both of these we will confirm on list thank you.

Reshad Rahman - If you don't have the outer container how do you have context?

Kent - Really just have top level name structure makes explicit the RFC 8040
description statement

> 4   9:30  15  Title:  YANG Based Instance Data Files Format
>               Presenter:  Balazs Lengyel
>               Draft: 
https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-05

Lada Lhotka - Not necessary to provide more use cases, indisputable that
instance data needs to be represented.

Balazs Lengyel - Will look into shortening that.

Lada - Can have standalone instance data that does not belong to any server,

Balazs - What do you mean by standalone?

Lada - Just some data that I need to validate.

Mahesh Jethanandani - I agree with Lada that we don't been more examples but be
do need to know where it can be used.

Lada - In some cases you have both.

Balaz - In some cases you can have partial datasets.

Open issues

Kent - How who you do that (indicate which revision is used)

Rob - You shouldn't have to have extra metadata in order to be able to parse an
instance datafile.

Balazs - You can write your instance data for all features supports.
        Compatible, ignoring of that additional data will work.

Rob - Move the detailed use cases to an appendix, if you write a draft about
server capabilities it will conflict with this draft

Balazs - I can make it shorter.

> 5   9:45  10  Title:  Handling Long Lines in Artwork in Internet-Drafts and
RFCs >               Presenter:  Adrian Farrel >               Draft: 
https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-08

Rob - There's no marker at the end of the folded data.

Adrian - In the source you hit the ned of the artwork tag.

Kent - We kept it (end marker) out of scope.
        If you look at plain text we don't support.

Adrian - Disagree with two of the chairs.

Kent - Source code tag would add begin and code end code.

> 6   9:55  15  Title:  Comparison of NMDA Datastores
>               Presenter:  Alex Clemm
>               Draft: 
https://tools.ietf.org/html/draft-ietf-netmod-nmda-diff-00

Lada - What you mean by encoding?

Alexander Clemm - The diff format.

Lada - Use a different word to describe the encoding to avoid confusion with
xml/json.

Lou - Generally - we avoid options that are not strictly necessary.

Alex - This proposed to use the yang patch format.

Kent - Not sure extending is preferable, to extending yang patch. We don't have
consensus on that yet

Alex - Third case is don't define multiple formats but keep the hook that
allows people to define their own.

Lada - There are some advantages to permitting different formats.
        Otherwise will have to wait for those diff formats to exist

Kent - I agree the diff format that we select may not be optimal.

Lada - We have been discussing a staging repository for which this diff format
could be used.
        what I heard Kent suggest is that we try to come up with a good format
        and if that doesn't work then fall back. Opposed to saying here's you
        mandatory format, and then saying do whatever you want later.

Joel - sounds like we have a milestone with 104

Christian Hopps - If we find the ideal format what do we do?

Lou - Not a fan of building the leaf for future items

Rob - Add in filtering by origin metadata on the input (clarification)?

> 7   10:10  10  Title:  Smart Filters for Push Updates
>               Presenter:  Alex Clemm
>               Draft: 
https://tools.ietf.org/html/draft-clemm-netmod-push-smart-filters-01

Michael Wang - do you need to define a more generic method, not just yang push?

Alex - should we define filter like average that goes yang push
        would not go there outside of the scope

Lou - How many people have read? (a few)

Rob - Question as to where this should be pursued

? - Would you implement these filters everywhere?

Alex - On top of yang push?

> 8   10:20  10 Title:  A YANG Data model for Event Management
>               Presenter:  Michael Wang
>               Draft: 
https://tools.ietf.org/html/draft-wwx-netmod-event-yang-00

Lou - Suggest that you work with the authors of the other drafts to coordinate.

Alex - Action and notification is not necessarily the same.

> 9   10:30  10  Title:  NMDA Base Notification for Applied Intended
Configuration >               Presenter:  Qin Wu >               Draft: 
https://tools.ietf.org/html/draft-wu-netmod-base-notification-nmda-00

Qin Wu - Discussion of draft is moving to NETMOD has been discussed before.

Kent - Where is the intended application to get sent?

Qin - Last one is sent after applied operation.

Kent - Useful for any clients that did not initiate toe commit

Rob - I didn't understand why there are to notifications for the end of the
event

Qin - Originally had a single event.

Rob - Best to have one event, with success or failure.

Kent - Could simply call it intended, updated.

Lou - How many have ready the draft? (a few)
        not sure their is commonality with the other two draft

> 10   10:40 10 Title:  Factory Default Setting
>               Presenter:  Qin Wu
>               Draft: 
https://tools.ietf.org/html/draft-wu-netmod-factory-default-01

Qin - Also move from netconf to netmod

Rob - Useful to talk about copy config RPC  (can also use this)

Qin - Was looking to make this transport independent

Rob - yeah document

Balazs - Doesn't work because target is required (requires NMDA)

Kent - RPC reset factory - Should be  described as different then reseting to
factory default

Lou - how many people who are interested? ( lots )
        How many people have read it? (fewer but a few)
        How many people to we should adopt this as the starting point for our
        work in this area? (quite a few) none opposed

> 11   10:50 10 Title:  BBF YANG Update
>               Presenter:  William Lupton
>               Draft:  N/A

William Lupton - Members contributing to IETF alarms work in CCAMP
        members contributing to IPFIX work
        still need to stick to the old non-NMDA RFCs as our base

Lou - Appreciate the update

(end of the meeting)

>         Session 2:
>         THURSDAY, November 8, 2018
>         1610-1810  Afternoon Session II
>         Chitlada 2
>       Audio stream:  http://ietf103streaming.dnsalias.net/ietf/ietf1035.m3u
>
> Presentation   Start Time  Duration  Information
> 1   16:10  10  Title:  Intro
>                Presenter:  Chairs
>                Draft:

Lou - commencing / note well
        agenda
        module tags
        versioning requirements
        yang versioning potential solutions

> 12   16:20  20 Title:  YANG Module Tags
>                Presenter:  Chris Hopps
>                Draft: 
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-03 Chris Presenting

Kent Watsen - would it make sense to call it "recommended-module-tags"?

Lou Berger - predefined sounds pretty good

Joel Jaeggli -  How many have read this draft or previous version.  A
reasonable number.
        Are there any people who object to any of the changes made during the
        last call.  There are none. I don't think that another last call is
        required.

Kent - can we add an example

Chris - what format would you like it in.

Kent: xml/netconf or json/restconf is fine, just identify which is used.

> 13   16:40  30 Title:  YANG Versioning Requirements
>                Presenter:  Joe Clarke (representing YANG Versioning DT)
>                Draft: 
https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-01

Joe Clark presenting

Discussion on new requirement slide 1.4

Rob S - why is this phrased in terms of a single module needs to have this?
        Some versioning based on the union of all the modules.
        Made the problem statement very specific not in a useful way for
        operators.

Joe - We recognize that our customers may want a bug fix that is not backwards
compatible.
        We talked about deviations - this is to describe the requirement not
        the feature.

Rob W - If you use a deviation you end losing?
Rob S - We have that problem already with sets
        Why is this within a single module, you want to be a able to change a
        module
Joe - The wording of this is there are multiple trains of software and there
are customers have a need to make fixes in historical versions and have a way
to identify those.

(jabber) Martin Borklund - + 1 to Rob Shakir.

Christian - Love the wording because it describes exactly what you want, and I
don't want
        As an operator I'm screwed because you don't have a single train that I
        can build my tools on If you restricted major version changes to
        non-structural I'd by ok with it.

        would like to see some justifications in the form of changes that
        cannot be achieved with other mechanisms

Joe - Would love to address to this with use cases.
        wording aside don't want to describe this as a solution.
        there could be a number of ways to solve this
        limiting branching
        null-pointer dereference is not going to require a module change

Lou - you also want to solve the user problem?

Joe - and we want to solve the user problem

Reshad - if you (Chris) there is never a reason to do a change this then we're
done.

Rob W - Goal is to address for bug fixes

Rob S  - perhaps a go thing to do is to explain the release problem because
that's the set of modules problem/lets stop making crap decisions about how to
fork our software.

Joe - Agree we talked about compatibility shims from a solutions standpoint.

Rob S - Lets write those down then.

Balazs - The operators come to us and say I don't want to upgrade the module
path the old one.

Rob S - Don't make it my problem please.

Rob  W / Rob S - Module deviations / is a way of handling bug fixes in old
modules.

Rob S - When we started the versioning was the only problem.

Chris - import by revision

Lou - Get a definition of a bug fix.

Joe - If you don't like software release trains, you won't like that
conversation.

Rob S - What vendors do anyway should not be endorsed by the IETF.

Lou - Perhaps we should document what we're prepared to agree and disagree on?

Next slide discussion on req 3.1 / 3.2

Rob S - Need to support this kind of module filtering anyway / added GNMI
specifically to handle this.

christian - Used to for example embed version numbers in sysctl(s).

Joe - We thought until about 10 minutes ago, that the requirements are complete.
        There is clearly some more work to be done.

Joe - if we don't have to come up a with a formal definition of a bug fix

Christian - May have to be a dissenter.

Rob S - I think we should remove the entire second sentence (from 1.4).
        The cost you're avoiding is the cost the operator already has to pay.

Kent - Needs rewriting.

Mikael Abrahamsson -  Agrees with Rob Shakir.

Rob S - So you have to support more than one version of the module?
have to support this combination - solution be entirely outside this problem
space

Tim Carey -  ???

Joe - would remove this first sentence

Tim - why would you ever mean the first sentence

Rob S - oct 2015 catalog registry for yang modules draft
we tried to describe it there

Rob S -  There are

Joe - Asking for adoption of the requirements is premature.

Lou - Would like you best effort at a description
        and then we can poll for adoption
        mark it as that. It is still under review?

Lou - how many people think that would be a suitable foundation for adoption

Rob S - will post an adoption comment

        (lots of hands a good number of people.)

> 14   17:10  50 Title:  YANG Versioning Potential Solutions
>                Presenter:  Rob Wilton (representing YANG Versioning DT)
>                Draft: 
https://tools.ietf.org/html/draft-verdt-netmod-yang-solutions-00

Rob Wilton presenting

Christian - Is this slide log scale? The solution space should be weighted
towards the users.

Lou - Does your evaluation cover all the requirements?

Rob W - No this is a subset.

Lou - But, we won't have a full solution until all the requirements are met.

Christian - Why would you apply a fix on 1.0 but not 1.1?

rob W - You wouldn't
        You're using deviations to take it down to a different version.

Rob S - You can always publish a module which can only augment a previous one.

Rob W - Benefits of semver are quite clear.

Rob S - What happens when I make a second backwards incompatible change?

Joe - talked about versions of this that would add a lot more complexity
      (slide modified semver)

Rob S - This tells you what kind of change got made.
        What do I do about that?
        We tried to do something like this; Sure it's an indicator of what you
        have to do, but it's not sufficient

Eliot Lear - option 5 - do nothing

Rob S - deprecated nodes should still be supported? what does that mean?

? (Ericisson) - don't agree with bullet 2

Rob S - the problem is unavoidable because we have no system that relies solely
on yang for interaction?

Rob W - Modified semver is the current front runner
        Import by version...

Christian - Client backwards compatibility - not fully explored

Lou - On hook for a writeup

Benoit Claise - Not all of have the luxury to start from scratch with models -
        I wish the IETF would produce some of those modules. It doesn't work
        that way at least for the vendors. Maybe what we could do is pretend
        this is a native modeling issue Document that in whatever  way we can.

Rob S - Would like to see that you can solve it with regular semver plus
deviations.

Christian - I think we understand you have issues to solve or that you
definitely can't solve them in the IETF.
        It a question of whether that should be in the requirements.

Rob W - Does the room feel like we're going in the right direction
        raise a hand?

Balazs - Ask a different question.

Lou - Until you start hitting the harder requirements I have trouble deciding
to early.
        continue on, don't abandon the hard problems.

Charles Eckel - Is semver or modified semver the right way forward?

Rob S - very happy with semver?
        Wider solution is how problem space entirely works

(end of the meeting)