Minutes IETF101: netmod
minutes-101-netmod-01

Minutes for the NETMOD WG Sessions at IETF 101
-----------------------------------------------------------------------------------------------

IETF 101, London, March 19-23, 2018

Two Sessions:
  TUESDAY, March 20, 2018 15:50-18:20 (Blenheim)
  WEDNESDAY, March 21, 2018 13:30-15:00 (Blenheim)

WG Chairs:
  Lou Berger <lberger at labn dot net>
  Joel Jaeggli <joelja at bogus dot com>
  Kent Watsen <kwatsen at juniper dot net>

Available During Sessions:
  Audio stream:  http://ietf101streaming.dnsalias.net/ietf/ietf1012.m3u
  Etherpad:      http://etherpad.tools.ietf.org/p/notes-ietf-101-netmod
  Meetecho:      http://www.meetecho.com/ietf101/netmod/
  Jabber:        xmpp:netmod@jabber.ietf.org?join/
  Slides:        https://datatracker.ietf.org/meeting/101/session/netmod

Available Post Sessions:
  Recording:     https://www.ietf.org/audio/ietf101/
  YouTube:       https://www.youtube.com/watch?v=e2iTr8EDlwA

TUESDAY, March 20, 2018 15:50-18:20 (Blenheim)
Afternoon Session II
Room: Blenheim
==============================================

Session Intro / WG Status
Chairs (15 minutes)
#1 Interface-ext & VLAN
Lou Berger: What's need to get interface-ext and VLAN drafts to Last Call?
Robert Wilton:
1) For interface-ext, there's not that much more to doing these drafts it's
really just adding some examples. I think that they should be ready for working
with last call, so there's not much further to do. 2) For intf-vlan-model, it
need checked with IEEE. Lou Berger: In order to do that check, do we need to do
a formal liaison or will you just handle it through informal you know people
working in both organizations? Robert Wilton: I'll do informally. #2 Liaison
response to IEEE & BBF: Benoit: I've seen those liaisons, I wanted to send
answer to those SDOs, and I was just waiting for the last piece -- the schema
mounts. So hopefully it will be done pretty soon.

Chartered items

  YANG Module Tags
  Chris Hopps: (10 minutes)
  https://tools.ietf.org/html/draft-ietf-netmod-module-tags-01

Robert Wilton: (Slides P3) One of the implications is that ‘mask tags’. It is
gonna be a list of things you're removing from the operational states, so in
the operational view of the data, you'd only see the tags list module tags. You
wouldn't see the masked type of the tags. This is an interesting case where
you've got some new configuring that then it doesn't appear in operational
state, it doesn't appear in the apply convict this effectively I can and
negative complicated. So I think goodness to think that through and check that
that's the right switch. Chris Hopps: We should look at it make sure it's the
right way. Benoit Claise: Are you going to use this yourself and when you have
your to change depending on that. Chris Hopps: I personally don't do our module
organization, so I can't say exactly how they're gonna use it. But I've
presumably the device model. Benoit Claise: What do you expect the vendor
within there? Chris Hopps:  I don't have expectations or anything. It's like
hashtags, I picture it more as something that's it's a not an obvious thing
that we do. We organize things and people may come up with new ways to use it.
The example that caused it to be birth was that the device model. Martin
Bjorklund: When we talk to device from an orchestrator and the device
advertisers, you sell modules, and there are some overlap, for example there
might be a native way of doing stuff, ietf standard way of doing stuff, and
openconfig way of doing stuff. And these models overlap or they provide the
same functionality, but your different modules. in that case it would be very
useful to find out which modules belong to itself, so that we can make it one
of them, so that's something I would like to see. Martin Bjorklund: Another
comment on this: if you consider using identity? Chris Hopps: No, I mean the
idea was to make it. So it (tag type) could organically be used organically, so
that the user could add them easily to the system, and so that would be done
sort of install routers or hardware in my system, and I want to add things.
Michael Wang: If you consider to define some metadata? Chris Hopps: There are
other mechanisms to actually tag instance data right. This is working on the
schema level.

  YANG Data Extensions
  Martin Bjorklund (10 minutes)
  https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-01

Kent Watsen: I think if you want to use groupings that the module designer has
to anticipate that the grouping would have to be fine, because they meant they
may actually have groupings to implement. But if they did that, that's great.
If they don't do that, could scheme mount be used? Martin Bjorklund:  Possibly.
For the other hand this yang data extension, it defines the data structure that
is not part of any datastore. It's something outside of datastore, so I
wouldn't think that schema mouth should be defined in this extension. Robert:
Keep it simple. Kent Watsen:  This draft say that anyone who wants to create a
yang to use this yang extension, that they must create a grouping, and then use
the grouping, and they're thereby ensuring the downstream compositions can
occur by using the grouping. Juergen Schoenwaelder: I prefer that extensions do
not define data nodes. Alex Clemm: I just want to mention this is important to
be solved. I don't know where the right place, but I think that is really a key
something that it's missing action framework and we need this. Martin
Bjorklund: The question is should we do it in this document. Maybe separate
documents will address it. Joe Clark: Ratify this and use this to focus on
something. More error focused in a different document. Kent Watsen: If we don't
do it now, then we would have to spin up another effort almost immediately.
Because there are dependencies from the yang push, and really the drafts need
to have this. Martin Bjorklund: This is more important to publish the basis
draft with a yang day extension. Alex Clemm: Just for future.

Non-Chartered items:

  New YANG Module Update Procedure
  Joe Clarke (10 minutes)
  https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-03

Christian: When you're deprecating, is there an ability to specify a time
duration? Joe Clark: We don't have a specific data element. We introduced for a
time bound deprecation but we talked about it in the text. Ruediger Volk: In
irregular software development rather than a deprecation date, I get the
version number that is going to duplicate with IETF process, kind of dates are
hard to predict. Version numbers can be managed. Chris Hopps: When you say you
don't want a date. Is that you don't want a date to be standardized or you
don't want to date from the vendor telling you when they're gonna stop
supporting it? Ruediger Volk: I mean you don't want to have to say I have to
obsolete this now, because I picked that day. There's something the data is
useless. Lou Berger: The date means is expect this to disappear unless you come
talk to us. A lot of distros have version and dates on which they'll stop
supporting their version Ruediger Volk: I'm just saying don't standardize don't
require a date. Benoit Claise: That's a thing right, because if you're a vendor
and you know to be duplicated and you know the version you can write, but if
you don't know it's going to push yourself a constraint just don't do it.  (you
need tooling) Lou Berger: I really like that approach, because it addresses the
issue of a server meaning to support older and newer clients at the same time.
It gives you a nice transition timeline. Lou Berger: It's not really changing
the module name, it's a new semantics to the xpath. It happens to be a change
of the path, but really it's just an encoding of the major version. Robert: A
patch level is useful, it is like a rafter on published module where you might
be modifying example description statements, but it's useful to say it has
changed, but the change is sort of insignificance. Lada Lhotka:  1) Suggest not
to introduce this, because sub-modules have their share of problems, and I
believe if they are used, then they should be really tightly coordinated and
the revisions can be included in yang version information, so I believe this is
not necessary to do it. 2) Patch number may be useful. Using patch semantic
version, it might be possible to keep the RFC unchanged. Chris Hopps:
Non-speaking as an operator. I want the namespace of change, it's backwards,
it's not compatible, I can't deploy and run a client against something where
there was a backwards incompatible thing. Lada Lhotka: I proposed to encode
derivation, not a date in the namespace. Chris Hopps: I wouldn't want revision
in this namespace, because it's not changing. If it's compatible, I can still
control that device, even though it's a newer version, I don't want to change
them. But for a major change, I can no longer use my client controller, so I
wanted to change light but only the major. Blaze: We allow incompatible changes
without name changing, or given today and changing the name is rather big, and
people like to see their connection. Martin Bjorklund: I think you're making
pretty fundamental changes to the yang language. There's probably need for a
new yang version, but he thinks the change for deprecated obsolete or something
that should definitely be pursued. Tom Petch: It too late.

Benoit Claise: I've been seeing different SDOs open-source project and also
vendors that we need to change the way we've been working. We could say we have
a good metric because the number of languages producing RFC are going up. If
people leave that you have the perfect yang modules, not use from now, because
an RFC. This is just wrong. Mahesh: Is there anything in the draft that
actually talks about how authors are supposed to keep track of the major minor
changes? Joe Clark: In this draft in terms of how one determines what is say
backwards-compatible, the concept of this derived semantic version. We've been
using in a tooling standpoint algorithmically to determine when the major, when
the minor, when the patch version would increment. Juergen Schoenwaelder
(jabber): I agree with Martin that changing the versioning is far reaching
impact and requires a new version of YANG. Jason Stern: I think what you're
saying is we have two forms of major breaking changing a module name and
changing a major version.

  A YANG Data Model for module revision management
  Michael Wang (15 minutes)
  https://tools.ietf.org/html/draft-wang-netmod-module-revision-management-00

Kent Watsen: Why are you defining a top of a model instead of augmenting yang
library? Michael Wang: Actually, we also augment the yang library. This model
is used to provide the update details. Robert:  This is something that's useful
to standardize or whether this is just something that we provide advice and
tolling? Michael Wang: I am not sure whether is better, defining a standard or
a tool, it depends on WG’s decision. But I think it is not a bad idea to define
an information document to guide user to do such works. Joe Clark: The semantic
version doesn't standalone by itself, you have to compare it to something. I
think from the tooling standpoint there's huge value in this. We've already
seen consumers they appreciate the output of that, but I don't know that alone,
what you are solve. I don't know that our proposal and your proposal conflict.
Michael Wang: I don't think to have some overlap, I believe that two solution
can compatible. I think they can work together. Your solution can help user to
know this version is big change version, or patch version. And our solution
help to reflect the update details. Carry (Nokia): This requires two things for
this to work. One is for people to provide it and the other is to have the
ability to consume it. I would suspect that if we're having problems with
vendors already that that say I'm not even adhere to a major, minor, patch. A
guideline that they're gonna be able to build all these individual constructs
and archives. It's a great idea. I'm just wondering if the industry would be
supportive of that as they define their modules and have that particular rigor
in place or require that particular rigor and that's my biggest concern. Joe
Clark: We don't expect any vendor to produce these artifacts what we've done in
our tooling. Jason Sterne: I'm not sure what the clients gonna do with this
list of dynamic information. Kent Watsen: Same concern. Michael Wang: In some
vendor systems may support different revisions of same module, and they can
check the change log list to decide if they need to update or synchronize all
of models which depend on this.

  Open discussion (0-20 min)
  Handling Revisions

(Miss name): I don't know how to solve this I can just assume user and operator
in your safe. I've had a lot of pain when it comes to going between different
versions. Kent Watsen: I think we need to be more things Chris Hopps: This is
not particularly an IETF thing, it relates to modules and yang. I think the
IETF can change, but one really painful thing that we've had is that vendors
are changing the modules of a ship like with every release in incompatible
ways. Kent Watsen: There's no guarantee that anything's backwards compatible
because we can't, but going to your other drop the module tags draft, so
there's standards modules, and there's vendor specific modules, so maybe this
would be very beneficial for standards which is our personal pain point and
then vendors can continue to be backwards. Balazs Lengyal: You can very fast
determine if it's compacted or not, and then you can try to use your software
that was prepared for the other compatible version. And I don't want to change
the module name or the namespace because all my scripts, all my software, will
stand down that namespace and that module name. I don't care about my being
compatible, but I don't care about that there's a change I have to investigate
it, and that I can decide what to do about it. Lou Berger: When you say that
you want to discover what's changed. You want to do that with the device or
would you like to do it with offline mechanism like a catalog based mechanism?
Balazs Lengyal: If I get the simple that's good for me what the changes are,
you can't find out more you lose compact were incompatible really
programmatically. Often we have the case when the model is not changed for the
behavior behind the model it's changed, so you will anyway need to study
manually. I would say that this detailed analysis, it's very useful. Charles:
This maybe being too late for in some regards, but I think through the need for
this type of thing is only going to increase a lot of requests or we need to
move faster when we move. So I think whatever mechanism we do, we've got in
order that it works very well for lots of backward compatible changes, that's
done to work very a little touch easy way to deal with that just. The faster we
try to put out yang models the more we're going to have to change. Kent Watsen:
Yang next that would be a long term solution, we really need a short-term
solution.  Can we work what is the word short-term solution? Balazs Lengyal:
That's what we are doing, we come to a new yang version. Chris Hopps: I'll
count that idea earlier. I don't think we need to change the language if we
were to put some semantics on the URL. I'm sympathetic to the people saying the
patch number was useful. Robert: Just adding in semantic version as an
extension or protection is fairly easy. Tom: We're too late to try and impose a
formal structure of major/minor patch and so on. Juergen Schoenwaelder:
Namespace is used by XML, JSON uses module names for the name space. So you
have to change the module name for a major revision. Lou Berger: How many think
the working group should be working on the topic of model versioning? (Good
number) Joel Jaeggli (via jabber): Agree that it is an important problem. We
need operational guidance on to work with that I can just say, I had pain, I
don't have other quickly the doctor please make me better. Lou Berger: How many
people would be willing to work on the problem, and with the understanding that
the first step is to define what problem we're gonna address. (Reasonable
number) Lou Berger: How many are willing to offer text. (Reasonable number) Lou
Berger: OK, we would like your names send it to netmod chairs. We're gonna talk
about maybe doing either an informal or formal design team.

Lou Berger: It's a design team to go work the problem, and the first step will
be the problems statements.

  YANG model for finite state machine
  Nicola Sambo (10 minutes)
  https://tools.ietf.org/html/draft-sambo-netmod-yang-fsm-02

Jason Sterne: I assume the idea is going to do maybe a configuration change,
just as if it was any other management client like netconf client. Nicola
Sambo: The use case of the transponder yes there is a configuration action. so
we reconfigure the modulation format and the fact. Jason Sterne: This action
which is trying to do a configuration change just like any other client it's
gonna get blocked. Because the management system is doing some edit configs,
doing a commit that could take seconds or a minute or however long it wants, if
this is just doing a standard commit like any other a standard configuration
change, and commit like any other client, then it's gonna be stuck behind any
locks by any other management stations. Nicola Sambo: We can we can think about
how to how to handle these issue. Joe Clark: What if nothing changes in that?
Nicola Sambo: If nothing changes that that it means that no transition is
triggered, and we stay in the same state, in the current state. Xiaojian: There
is maybe need a detection mechanism. Nicola Sambo: We can execute actions in
sequence but we can also think to execute actions in parallel. Kent Watsen: May
have overlap with ECA model. Lou Berger: The next step is to talk with ECA
model and see if you could get them work together.

  Document Conventions for Handling Long Lines in Artwork Containing Code
  Qin Wu (10 minutes)
  https://tools.ietf.org/html/draft-wu-netmod-yang-xml-doc-conventions-00

Kent Watsen: As a contributor I think this is an important problem solve, and
this is a unique to XML now, like to cover Json and other formats. Balazs
Lengyal: We need a convention. Benoit Claise: It's a larger problem. Kent
Watsen: Make it simple so we can get a solution now faster but I would say this
is a lot more complex than what I proposed. Lou Berger: This is something that
could just be solved through tooling. Do we need a document on it? Benoit
Claise: You know just having a convention there would be way more helpful.
Robert: I think it's a useful problem to solve. Just pick one that's quite
simple to do and just move with it fast. Martin Bjorklund: I think we should do
this. I agree with Kent to make it simple. Lou Berger: How many people think
that this problem is something we should solve in the working group?
(Reasonable number) Lou Berger: How many think that this draft is a good
foundation a good starting point for the working group? (Reasonable number) Lou
Berger: How many people would like to talk and tell us why they think it's not
a good idea to start with this document? Charles: It gonna be too complicated.
I just like the very simple.

  YANG Instance Data Files and their use for Documenting Server Capabilities
  Balazs Lengyel (10 min)
  https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00

Robert: I like this work useful. In terms of your model definition, you using
metadata, not using regular leaves, there is not clear to me. Balazs Lengyal:
Because this is actually metadata about the instance data set. It's not real
data. Robert: Other comment is you've defined XML, JSON format I think also
again doing a binary encoding, it could be useful. Joe Clark: Yes, we there's
value. Balazs Lengyal: I would add that yang module tags as one more use case.
Lada Lhotka: An adoption is to define this instance data as a normal container,
and the scheme mount for inserting or building this are not supposed. Martin
Bjorklund: Help to have top level stuff in here. Kent Watsen: I agree with
Martin, I think it is an useful work, but I also thought that yang might have
been a better approach for approaching this.

WEDNESDAY, March 21, 2018 13:30-15:00 (Blenheim)
Afternoon Session I
Room: Blenheim
Video Recording: https://www.youtube.com/watch?v=wI4oHJ9_4KE
================================================

Session Intro
Chairs (10 minutes)

Schema Mount : Resolving Last Call Comments
  Martin Bjorklund (20 min)
  https://tools.ietf.org/html/draft-ietf-netmod-schema-mount

Kent Watsen: Is a presence container really necessary?
Martin Bjorklund: No.  We don't want to require parent reference.
Benoit Claise: Next steps - new version, then Last Call for two weeks for full
review. Lou Berger: v09 might be sufficient.  Based on comments, a v10 might be
necessary, but not a given. Benoit Claise: are the NMDA compliance statements
currently included? Martin Bjorklund: It should state that it coveres both NMDA
and non NMDA servers.

Long Term rfc7895bis / NMDA Schema Mount Support Discussion
  Ladislav Lhotka (20 min)
  Martin Bjorklund (20 min)

Rob Wilton: this means you can embed a schema anywhere?
Lada Lhotka: yes.
Jason Sterne: does this mean can only embed one schema at a node?
Lada Lhotka: not sure if we need to worry about multiple schema at same target.
Martin Bjorklund: so Jason's point, I mean you wouldn't with this proposal you
would not support what we have today and that any use case requires where you
could have possibly different schemas at different instances of the same mount
point. It explicitly does not support this case. Lada Lhotka: this does not
support in-line case Martin Bjorklund: so this would be use in addition to the
existing schema mount? Lada Lhotka: yes Lou Berger: What is a schema-node-id
(on slide 4) Lada Lhotka:  Same syntax as we use for augment Robert: Are we are
also standardizing instance data? Lada Lhotka: We would have examples in the
documentation Balazs Lengyal: it is fine for instance data to be a prescriptive
part of an RFC Lou Berger: the node we are augmenting might have other
children, and could this drive complexity?  Maybe this is a designer's choice
(just put in a restriction to avoid collisions.) Martin Bjorklund: augment is
different from a Mounted Schema because the mount implementation cannot place
the same constraints on execution environment Balazs Lengyal: you should take
just as much care in implementation of both Lou Berger: should we consider
design-time mounts? Lada Lhotka: would need a new YANG 2.0 for this. Balazs
Lengyal: The YANG library instance data does in effect give you design time
mounts. Lada Lhotka: we need to make sure design time mounts mean the same
things to both Lou & Balazs Lengyal: would love to have a statement of what can
be supported in the draft. Lou Berger: A mounted schema might have dependencies
specific to that module which need to be documented and expressed Martin
Bjorklund: instance documentation in RFC might also result in deviations (how
would these be documented?) Robert: can provide text rather than instance data
in RFC as a way of avoiding such complexities Lou Berger: we can determine
whether this is in WG scope after someone comes up with a proposal to consider.
Lada Lhotka: so this would Obsolete SM-09 Martin Bjorklund: more like it,
updates it Lada Lhotka: prefer to keep inline and use-schema cases separate
Martin Bjorklund: This would make library complex. Tim: did you say this
solution just get used with NMDA? Martin Bjorklund: can work with non-NMDA
elements, and pre-NMDA solutions as well.

Discussion (20 min)

Rob Wilton: What is see difference between solutions is how heavyweight the
solution is.  Heavyweight favors Martin's solution, lighter weight matches
better to Lada's proposal.  Prefer heavyweight.

Balazs Lengyal: worried about level of complexity from the many proposals.
Lou Berger: This is the start of a discussion, and is should converge.

Discrepancy detection between NMDA datastores (Alex Clemm)
https://tools.ietf.org/html/draft-clemm-netconf-nmda-diff-02
https://datatracker.ietf.org/doc/slides-101-netconf-discrepancy-detection-between-nmda-datastores/02/

Robert: what level of comparisons validly can be done across different
datastores (e.g., intended and operational)?  Expect nuances. Alex Clemm: the
intent is to compare data which propagates between datastores. Martin
Bjorklund: just compare the nodes which are actually in the different
datastores.  Put this explicitly in the draft. Martin Bjorklund: need to
explain how the filters are supposed to work.  I.e., defining a common
selection. Martin Bjorklund: this is important work, and should be done. Rob
Wilton: thinks it generally useful Lada Lhotka: supports the work.  As for
filters, use something simple.  Perhaps just root and depth of trees. Martin
Bjorklund: subtree and xpath filters are available Lou Berger: Please publish
on NETMOD, and get ready for comments.

Generalized Network Control Automation YANG Model (Igor Bryskin)
https://tools.ietf.org/html/draft-bryskin-netconf-automation-yang-01

Lou Berger: this seemed a model based thing rather than something protocol
(which would place this in NETCONF) Kent Watsen: seems to be partial overlap
with FSM work.   Need continuing discussions.  TBD Igor Bryskin: doesn't feel
like there is lots of overlap Kent Watsen: continuing discussions should happen
here Interest from room:  (a 'reasonable' number of hands)