Minutes IETF100: netmod
minutes-100-netmod-00

                        NETMOD Minutes IETF100
Version: Nov 14, 2017
Session 1:
WEDNESDAY, November 15, 2017
1330-1500  Afternoon Session I
Sophia
Audio Recording:       
https://www.ietf.org/audio/ietf100/ietf100-sophia-20171115-1330.mp3 YouTube:   
    https://www.youtube.com/watch?v=-5LJyVJVuPQ

Session 2:
WEDNESDAY, November 15, 2017
1520-1650  Afternoon Session II
Sophia
Audio Recording:
https://www.ietf.org/audio/ietf100/ietf100-sophia-20171115-1520.mp3 YouTube:   
    https://www.youtube.com/watch?v=x7go1IxMZXc

Etherpad:
http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-netmod
Jabber: xmpp:netmod@jabber.ietf.org?join
Session 1

Presentation            Start Time      Duration        Information
0               13:30   10      Title:  Intro, Charter & WG Status
Presenter:      Chairs
#0.1 IEEE and BBF Liaisons:
Tim Carey: BBF Liaison is similar to the IEEE. NMDA is now out there and
standards organizations are trying to figure out what to do right, because they
base models like on 7223. They split the config and operation. Now NMDA are
bringing them back together. There needs to be some guidance. NMDA stable? When
will it be complete? How long will be keep the -state in the appendix? Lou
Berger: You should follow the refactoring approach that we're taking on our
existing RFC's including having the stateful version in the appendix. Do you
see that type of response causing being well received? Tim Carey: I think
they're willing to accept that. They would want to know, in the interim, how
long would we be doing like the state model separation? Lou Berger: The current
of recommendation within the ietf. I would be hard pressed to see that it would
be different outside of ietf. But one of the nice thing about the
recommendations with having this these modules in the appendix. It is that sort
of is good risk mitigation because you can go down that path while the other
parts being developed without any concern about in long term incompatibilities.
Lou Berger: Call for volunteer for draft liaisons response. (Michael volunteer
to handle it) Benoit Claise: This week we had a meeting with IEEE management
team. We went the same thing. The point is that we've got multiple source of
information, we've got like the tool that Rob wrote on converting things. I
could select all yang modules of IEEE and see States via catalog. I think that
what we need to do is be proactive and contact all the different SDOs in the
most project that are dependencies on or yang module and explain what the
guidelines of the tool. Tim Carey: One of the things I know from the BBF
perspective is, they want to make sure that the state models will exist for a
period of time, because they've got stuff that they just published and they got
to react right. Kent Watsen: You're asking about the state modules that we're
publishing in the appendices of various RFC's? Tim Carey: Yeah. When we do nmda
that we would also do state version of the thing. We keep doing that for a
period of time until the industry can get their stuff then reformed up. Kent
Watsen: I don't think we've ever put a timeline as to how long we would
continue doing that, but I assume we would continue doing that for as long as
the market needed it.

# 0.2 Current Milestones
# 0.2.1 interface-extension
Lou Berger: Do you think the documents will be ready for last call?
Robert Wilton: On (draft-ietf-netmod-intf-ext-yang) I need to add examples into
that document. So that one's not far away. The problem one is the sub interface
yang (draft-ietf-netmod-sub-intf-vlan-yang), I changed the structure to
simplify it, and IEEE had some concerns with that. So, I need to follow up with
them to check that they're happy with it. The current structure in terms of how
the VR tags are represented. So, it depends on how quickly that goes. They say
fine then then it's ready, they say no then there be more discussion.

Draft:  N/A
1               13:40   15      Title:  Post LC Update: Schema Mount
Presenter:      Ladislav Lhotka
Draft:  https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-08

# 1.1 Prefix/namespace declaration
  option 1. no change;
  option 2. replace uri with module name;
  option 3. use both URI and module name
Lou Berger: As both contributor and chair, we have gone to the last call on
this unless there's a specific issue that we're fixing we should not make the
change. Ladislav Lhotka: Authors prefer one (no change). Dean Bogdanovic: I go
for no change, but if we would agree all to change, then I would say go with
option number three.

# 1.2 NMDA Support
Dean Bogdanovic: This isn't in the real life scenario. This is a theoretical
corner case. Ladislav Lhotka: yeah, it is as I said it's possible that it will
never happen, but the schema case is really general. So you can use it as
augments anywhere and don't care about anything in this case. It is just this
small catch. I'm not saying it's a big problem, but we have to I care about
this. Dean Bogdanovic: I really don't see it as a real-life problem. Dean
Bogdanovic: WRT slide 5 (NACM Considerations): Regard to the rules from the LNE
perspective they are really important. Data coming up with the rules in this
document will just delay the schema mount. And we really learn what rules would
we really need as a minimum. I suggest to put it in NACM. Ladislav Lhotka: It
also make sense because this schema mount mechanism is designed to work without
NACM. Kent Watsen: 6536bis is already with the IESG Lou Berger: Is there an
issue with the NI case? Ladislav Lhotka: No NACM works with NI case. Lou
Berger:  LNE with managed=true is the same case as NI so should be okay. With
managed=false. no access is supported from the parent context -- basically
schema mount isn't used in this case. Dean Bogdanovic: Agrees that this isn't
an issue with the LNE case. Martin Björklund (via Jabber): @mic: I think it is
better in this document. Martin Björklund (via Jabber): @mic: the LNE data is
readable from the parent. Martin Björklund (via Jabber): @mic: no it should be
protected by NACM. Martin Björklund (via Jabber): I think we MUST handle NACM,
for any mounted data, since it is readable.

# 1.3 YANG Library & Schema Mount Integration
Robert Wilton: YANG Library is currently open for update
Re: slide 7 (Proposed Re-Organization):
Lou Berger: given post-LC, a doc re-org would cause a reset. Is it really
needed? You have also raised this comment multiple times as the document has
progressed, and we have agreed to keep in one document. Martin Björklund (from
Jabber): I don't want to split the doc Martin Björklund (via Jabber): we've
discussed this before.  it's just a split of the content. Dean Bogdanovic:
Splitting is the wrong exercise to do and what we have is good enough to move
forward.

2               13:55   15      Title:  Post LC Update: ACL Update
Presenter:      Sonal Agarwal
Draft:  https://tools.ietf.org/html/draft-ietf-netmod-acl-model-14
# 2.1 Support for different combinations of statistics

Re: slide #3 (Support for different combinations of statistics):
Dean Bogdanovic: The stats collection and the A are highly dependent on the
basic implementation. Most can do that only on the ingress side, and not on
many of them will have collection on the egress. So, in this case, you sent
what you’re trying to put onto something that will not always work on all
implementations. Sonal Agarwal: The model allows collection on either. Mahesh
Jethanandani: Stats collection can be either ingress and/or egress. Dean
Bogdanovic: Why not just do this as an ACL with an action counter? This is a
standard way to implement it (that avoids the issue). Mahesh Jethanandani: We
should take this offline

# 2.2 Slide 4
Dean Bogdanovic: Support for ACL-set application on interface:
Dean Bogdanovic: Is list of ACLs an ACL topology, applied to one interface? In
many implementations, only one ACL is supported per interface.You cannot have
different topologies except serial ones is a pretty hard limitation on some of
them, you can put them. Robert Wilton: Vendors can put a deviation on the model
to restrict the list length to a maximum of one element, if they can only
support a single ACL per interface. Sonal Agarwal: We can add that in.

# 2.3 Open Issues (slide 7):
John Easly: You were saying the different types of ACL you're referring to
ethernet, V4 and v6, right? Sonal Agarwal: Yes, there can also be mixed types.
Dean Bogdanovic: ACL model is getting complicated, turn into such a mess with
deviations from the vendors. Can we create a simple base model and then have
extensions? Rick Taylor: May want to ACLs in software and match on any fields.
Jeffrey Haas (via Jabber): @mic: In order to do a base model and extensions,
you must first know what the expanded form would look like. Mahesh
Jethanandani: To address Dean's concerns around creating a base model, you can
declare feature "eth" and get just the "eth" container. Cannot make it more
basic than that. Dean Bogdanovic: right now vendors want something common and
simple, not overly complex.

3               14:20   5       Title:  Session 2 kickoff: Handling Revisions
Presenter:      Chairs
Draft:  N/A

4               14:10   10      Title:  Example of major revision change:
rfc8022bis Presenter:      Acee Lindem Draft: 
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-01

5               14:25   20      Title:  YANG Revisions
Presenter:      Benoit Claise
Draft:  https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-00

6               14:45   15      Title:  YANG Revisions Discussion
Presenter:      Chairs
Draft:  N/A

Kent Watsen: We're only able to implement a single version of a module at a
time. This works because of the backward compatibility. Would we need to for
instance support multiple versions of module to enable both backwards
compatible view of the legacy version and also the new version? Benoit Claise:
Not in a server on a typical router; but maybe in an Orchestrator or
controller, where there is like service composition coming from multiple
network elements that might be the case. Lou Berger: One of the things that
we've been trying really hard to fix with yang is the problem we have with CLI,
when the version changes on the CLI on a router the user has to change their
tooling. I think we're at run a risk of repeating the same thing here, if we
don't allow a server to export both the old and the new, and allow the user to
choose what they use. Benoit Claise: We could export multiple who wants library
but only one could be implemented. Now you want to give the choice to say I'm
exporting new one and the old one you could advertise them, and you expect that
one controller or one Orchestrator will say which one to use. Lou Berger: We
have to be careful here because if we're not careful we'll end up repeating the
same problems or reintroducing the same problems we've tried to get away from
with yang. A customer has a deployment there, they have some old software and
they have some new software, they want to be able to keep the old software
running and they upgrade your router, but they also want to be able to use the
new software. Yes maybe on a particular session you would only use one version
and that might be the compromise, but you would want the server to be able to
support both the old and the new. Benoit Claise: Is this an issue which is
introduced by this proposal? Lou Berger: It is. In the current requirements you
can't have it. Because the current requirement is to always be backward
compatible. We're trying to say, let's be careful and think about it. Ladislav
Lhotka: First of all, I would like to say that I support this effort. Second, I
believe it would be useful to move the update rules away from the specification
of yang. And maybe define them in the draft just to say what changes, what
updates, are possible within one minor version, and so on. Because I believe in
the definition of that data, our modeling language such a policy really has no
place, because I can imagine that some groups may use yang even with slightly
different meaning of the versioning rules. So, I've been against these update
rules in RFC 7950 for a long time, so that would be my proposal to really do it
now and move away from the current restrictive rules. Balazs Lengyel: Based on
the long mail I sent yesterday. Even today we allow backward incompatible
changes due to the deprecate rule. Lou Berger: Current rules define “deprecate”
to support a transition period where support is phased out before being
removed.  The point of the rfc8022 was that we were *not* using deprecated but
jumping straight to obsolete. Balazs Lengyel: I disagree, the rules allow
immediate removal as it doesn’t state MUST support when deprecated.  The other
main point is  this is also a big problem for OSS for any network management
software. If I get the device with the newer model, can I still work with it,
like I did with the old? Or is it dangerous because there are unknown changes?
So work is absolutely needed. I feel that packages could handy handled
separately. Benoit Claise: I agree with this last point. Balazs Lengyel: I
recommend semantic revision be required on all future models. Also will we keep
the prefix, or if we change the prefix, we have the item data migration problem
because we have to go and find all the stored updates in the file system of the
operator, and change the prefix there as well. Martin Björklund (via Jabber):
@mic, to Balazs - a server can remove an entire current module if it wants to
in a new software version on the server. Jeffrey Haas (via Jabber): @mic: This
issue is somewhat analogous to the issue of multiple modules managing similar
information.  For example, the BGP module, which we have openconfig and one
still working through IETF. Basically, structural mapping. Robert Wilton: 1)   
  I strongly support this. I think that to change a module's name and the
prefix whenever you ought to do a major version change is a real hassle for
everyone involved. 2)      I also quite like Lou's point that you use github
develop these modules and want to put patch changes and things like that. That
quite well in terms of how you naturally manage this. Developers are also very
used to using this sort of version scheme. So, it's not like it's a brand new
scheme that people don't understand. It's a scheme that's well used in the
industry seems to work. It seems to be well understood. I also agree with the
suggestion, that import by revision effect needs to be fixed. 3)      Perhaps
the issue came up about having to support two versions of the same module in
terms of upgrade ability. That perhaps could be solved by you configuring on
the device which version you want the device to provide, allowed to different
clients both to access the different versions. But it does allow some control
of which version it's going to export. Dean Bogdanovic: I support this work.
Balazs Lengyel: My basic problems are 1)      Non-backward compatible (NBC)
changes should be allowed in some limited cases 2)       It should be possible
to determine two module versions' compatibility without a line-by-line
comparison 3)      It should be possible to indicate that a part of a schema is
deprecated, but is still present, implemented and usable Jeffrey Haas (via
Jabber): The issue isn't necessarily two versions of same module, it's the
blast radius effect. You update a major module, you have to upgrade the entire
ecosystem. Ladislav Lhotka: it's okay to reuse a prefix Benoit Claise: Lets
agree on the problem(s) we want to solve Robert Wilton: Need to be careful on
packaging implications Balazs Lengyel: 1)      I need a small bit of
information like the module name combined with the semantic version that tells
me if this version of the module is compatible or not with the previous one. 2)
     We want to allow some level of incompatible changes the routing and some
others stated. They should be indicated clearly. Lou Berger: We must agree on
the problem statement, we have a rough problem statement (slide 2 of chairs
slide), and it appears from comments in the room that this is sufficient for to
start thinking about solutions.  Please think about solutions and discuss on
the list.  Given the importance of this topic we’re likely to have an interim
on the topic. Sue Hares: are augmentations covered Lou Berger: Yes they must be
covered. Robert Wilton: Don’t forget about imports Dean Bogdanovic: RestConf
Api version also need to be supported? Lou Berger: Should support all protocols
(netconf, restconf, etc.) Benoit Claise: Can we agree that the proposed
solutions go in the direction of keeping the YANG module names? Lou Berger:
This has to be discussed in the context of the specific solution.

Adjourn         14:25

                                        Session 2:
WEDNESDAY, November 15, 2017
1520-1650  Afternoon Session II
Sophia
Audio Recording:
https://www.ietf.org/audio/ietf100/ietf100-sophia-20171115-1520.mp3 YouTube:   
    https://www.youtube.com/watch?v=x7go1IxMZXc

Presentation            Start Time      Duration        Information
0               15:20   5       Title:  Intro
Presenter:      Chairs
Draft:  N/A

7               15:25   20      Title:  Post LC Update: Revised Datastores
Presenter:      Robert Wilton
Draft:  https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-06
# 7.1.  Datastore schema & conformance Re: slide #8):
John Easly: would like to seem all terms in drafts
Robert Wilton: no ambiguity in this draft, the ambiguity is actually in schema
mount John Easly: I would say as long as you can actually determine. That link
between the two documents to find that definition would be sufficient, but to
leave them undefined, I think is a bad course.

# 7.2.  Actions/RPCs   (Re: slide #11) :
Lou Berger: is it possible for the RPC/action to define where it operates
Robert Wilton: this is already the case
Lou Berger: need to ensure that it's adequately covered
Sue Hares: ephemeral datastore may be resolve by rpc?
Robert Wilton: The issue is not about where the RPC is acting, the issues about
any parameters. So if you've got parameters that have to be evaluated against a
different datastore, then that would require future work. That requires new
work. Martin Björklund (via Jabber): which I2RS drafts has those RPCs? Sue
Hares: RIB. Tim Carey: how can we execute action for a node that is dependent
on the presence of hardware? Robert Wilton: can't, unless we introduce a
parameter to the action statement that specifies a datastore Christian Hopps:
We could use function terminology in which case an RPC. It would actually be
the inputs. Martin Björklund (via Jabber): these RPCs seem the work today as
they're using strings, not leafrefs Sue Hares: look at the next hop id Robert
Wilton: are we happy with this update? Lou Berger: yes, just need to check on
the language Lou Berger: we've reached the threshold of changes where we will
need to do another LC

8               15:45   15      Title:  YANG Tree Diagrams
Presenter:      Lou Berger
Draft:  https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-02
# 8.1. Re: slide #4 (3 options):
1)      all guidelines in 6087bis;
2)      all guidelines in a wiki;
3)      all guidelines in this documents
Lou Berger: prefers option #3
Robert Wilton: prefers wiki (option #2)
Christian Hopps: agrees with Rob, prefers wiki (option #3)
Robert Wilton: also for 6087bis
Tim Carey: also seems to prefer wiki
Mahesh Jethanandani:
1) Prefers option #3
2) Whatever we decide we better have a clear guideline because we have people
waiting on their documents wanting to publish, but since this document is not
making progress. 3) If it becomes an RFC, would this be a normative or
infinitive reference? Lou Berger: I think this is an informative. Because it
doesn't go on the wire and it's not a best common practice for a protocol.
Balazs Lengyel: prefer #3 Lou Berger: coding standard update Benoit Claise:
informational, yes Benoit Claise: prefers #1 Robert Wilton: re: IEEE looking at
6087 (not 6087bis) Ladislav Lhotka: support #2 Christian Hopps: do both draft
and WIKI, make it as #4 Mehmet: not happy with these options, supports option
#2 Martin Björklund (via Jabber): support #3

Kent Watsen: (polling) :
support #1 -- a few
support #2 -- a good number
support #3 -- a good number
support #4 -- a few

9               16:00   10      Title:  YANG module for yangcatalog.org
Presenter:      Joe Clarke
Draft:  https://tools.ietf.org/html/draft-clacla-netmod-model-catalog-02
Joe Clarke: Clarification on the presentation: my wording implied one can only
do diffs when the MAJOR version changes.  This is not the case.  We present the
diffs in the API if there is _any_ change to the versions for a given module
name Ladislav Lhotka: would be a good idea if the metadata could go into the
module itself.

10              16:10   15      Title:  Module tags
Presenter:      Christian Hopps
Draft:  https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02
Christian Presenting
Robert Wilton: I think it's useful. I prefer the solution in terms of the
configuration. I think that's fair discussion there, but generally yes, I'm
positive on. Kent Watsen: (poll): How many think this is a problem that the WG
should work on: A few How many think this is a document that should be adopted:
The same

11              16:25   10      Title:  YANG Data Extensions
Presenter:      Kent Watsen
Draft:  https://tools.ietf.org/html/draft-bierman-netmod-yang-data-ext-01
Ladislav Lhotka: why not use augment
Martin Björklund (via Jabber): Augment doesn't know anything about extensions
Use case for "uses-yang-data" in ANIMA with the voucher draft.
Eric Voit: Support because we need it in the NETCONF notification draft(s)
Lou Berger: Sounds like this is work needed by another WG and this WG is the
right place for this work. Lou Berger (polling): How many have read: very few
How many think this work should be adopted: a little more How many think it
should not be adopted: none Lou Berger: Expect to move towards adoption on list
Robert Wilton: This should be adopted and moved along quickly Juergen
Schoenwaelder (via Jabber): the scope of the work remains unclear.

12              16:35   10      Title:  YANG for FSMs
Presenter:      Nicola Sambo
Draft:  https://tools.ietf.org/html/draft-sambo-netmod-yang-fsm-00
 Gabriele Galimberti?: Would be possible to add the output of the state machine
 related to the state, instead of only to the transition?
Nicola Sambo: yes, this can be done, can be clarified in an update.
Christian Hopps: where are the FSMs? - are they already there, or are these new
ones? Nicola Sambo: aims to be generic, covering a couple of use-cases Lou
Berger: Currently FSM has to be known by both client and server Nicola Sambo:
The functions can be defined in the list action Lou Berger: not clear what
flexibility the client has? Robert Wilton: Not sure if there is enough support.
But generally useful to standardize a common capability. Lou Berger: not
sufficiently clear at this point for the WG to decide if something that should
be worked on in this WG Eric Voit: NETCONF working on something similar (Igor
Bryskin) and perhaps work on a joint problem statement for the WG.6 Alex Clemm:
Same comments, need add some problem statements.

13              16:45   5       Title:  ARP YANG Model
Presenter:      Xiaojian Ding
Draft:  https://tools.ietf.org/html/draft-ding-netmod-arp-yang-model-00
Lou Berger: Will it also be presented in RTGWG?
Xiaojian Ding: Yes, I will also present it in rtgwg.