Minutes IETF99: netmod
minutes-99-netmod-02

NETMOD Agenda IETF 99

Session 1:
MONDAY, July 17, 2017
1550-1720  Afternoon Session II
Congress Hall I
Audio stream:  http://ietf99streaming.dnsalias.net/ietf/ietf993.m3u

Session 2:
WEDNESDAY, July 19, 2017
1330-1500  Afternoon Session I
Congress Hall I
Audio stream:  http://ietf99streaming.dnsalias.net/ietf/ietf993.m3u

Slides:    https://datatracker.ietf.org/meeting/99/session/netmod
Etherpad: 
http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-netmod?useMonospaceFont=true
Meetecho:  http://www.meetecho.com/ietf99/netmod Jabber:   
xmpp:netmod@jabber.ietf.org?join

Available post session:
Recording:  https://www.ietf.org/audio/ietf99/
YouTube:    https://www.youtube.com/watch?v=r_bw099k6Hg

> Session 1
> Num Start #Min Information
> 0   15:50  10  Title:  Intro, Charter & WG Status
>                Presenter:  Chairs
>                Draft:

Andy Bierman: Entity draft being updated to reflect NMDA. It's probably close
to being ready

Lou Berger: OK that it'd be great if we could see an update in short order. So
we can go to last call - all raised issues should be resolved at this point.

Tim Carey: Can I just get a clarification. It looks like then entity will
probably be the first draft that will see the data store guidelines if you will
include it in?

Lou Berger: Are you talking about first to publication request or first
published?

Tim Carey: I guess it will probably be the first publish.

Lou Berger: There are other internet drafts that have already been refactor to
the format NMDA. I think we have a good examples, if you're looking for an
example there are ones that are far more complex than this one. This is
actually a pretty simple model. In terms of what we submit it to IESG for
publication. I certainly hope that this is out very soon. So, it is likely to
be the first one submitted by this working work.

Benoit Claise: It might be a good to some liaison statement to a different SDO
which is doing yang models to explain our NMDA right

Lou Berger: That's actually an excellent idea. The one question is do we wait
until we have agreement on the guidelines text from the working group, which we
don't have yet, or go just based on the AD's recommendation that's been
distributed? Maybe some who work in other SDOs might have a view on this.

Benoit Claise: I think we could do both. For example, it was mentioned in the
IEEE IESG meeting this week. I forgot to mention that we could have a formal
email, because we have the contact. One of our good text ready then we
mentioned that.

William Lupton: Representing for BBF, we are welcoming liaison telling us about
NMDA. But equally, of course when it already.

> 1   16:00  10  Title:  Network Access Control List (ACL) YANG Data Model
>                Presenter:  Sonal Agarwal
>                Draft: 
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-11

Kent Watsen: Regarding the open issues, are there going to be technical changes
?

Sonal Agarwal: Yes, and actually adding the "containers" that needs some
thoughts on how we want to do. But I've already gotten some ideas. I've spoken
to various people.

Kent Watsen: OK, how many people have read this version of the draft, which is
in last call. (a few)

Lou Berger: At this point we may want to send a message to the list letting all
know there is going to be another version, and then do another last call.

Benoit Claise: When will the next version be available?

Sonal Agarwal: November.

Mehesh Jethanandani (speaking as co-author): I think we should be able to do a
little better than November. We should have an update within the next month.

> 2   16:10  20  Title:  Revised Datastores
>                Presenter:  Robert Wilton
>                Draft: 
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-03

Mehmet Ensue:  what is your proposal for the handling of the term configuration
in NETCONF RFC (RFC6241)? Are You proposing to replace it? revise it? delete it?

Robert Wilton: I don't know. I guess we're going to supersede it effectively.

Mehmet Ensue:  So we have here a new term definition. We should be interested
to decide how we want to handle the old term definition. It can be deleted I
mean in Netconf this RFC? Or the same can be used there too but copy and paste
is not good.

Lou Berger: Which RFC are you thinking about?

Mehmet Ensue: The Netconf protocol RFC.

Lou Berger: I think then it's a good question for the Netconf working group.

Mehmet Ensue: Yes, but I assume you would have a proposal how to handle it.

Lou Berger: One option is that this document lists is updating that RFC and we
can identify that the update is in the name. The other option is that the
supporting documents that are going on in Netconf. I would defer to the
Netfconf chairs on how they would like to do.

Mehmet Ensue: That needs to be a discussion in Netconf for sure. It would be
probably consistent to remove this term from Netconf this RFC and refer to NDMA
RFC.

Lou Berger: that's a fine solution

Kent Watsen: And also add to that many times in drafts when they're importing
terms from other drafts, they specify which draft that are importing the term
from. So you know for the term configuration, they could indicate specifically
it's the old or the current Netconf RFC or the new revised datastore.

David Lamparter: I agree with default values in schemas, because it's not only
the device that needs to be aware that the absence of the value, something
different from the default value, but it's also the client libraries and
everything that passes through in the middle. So I think there's a requirement
here to kind of maybe not even have the default of the schema in the best case,
because otherwise you're still trading on thin ice.

Robert Wilton: Yes, in the particular case you've got configure then a
configuration node often has a default value associated with it, and that
configuration knows exists in the operational state they store as well, so you
have it often in the schema, but what I'm saying is in this case you would
return that value if it's in use.

Andy Bierman: The reason for suppressing defaults was to improve the transfer
efficiency. So if you have a whole bunch of stuff that's in the default value
and you're wasting 60% of your packet with stuff that's redundant, you don't
get that efficiency. So now you're saying we don't care about efficiency, we're
gonna send all the values all the time.

Robert Wilton: No, We want to get a definition of “in use”. That doesn't mean
that we throw back a lot of irrelevant data, but we try and find that so scope
sensibly that the default values you get back. Ones you might be interested in.
So if OSPF is turned off you don't return all the default values for OSPF that
aren't of interest, but it means that OSPF turned on then you do return those
values

Andy Bierman: It seems that explicit mode is clearly not useful because you're
talking about read-only data, so it can't be explicitly set to the default
value. So only trim really matters which is if the nodes not there then it must
be using the yang default and I think that definition is rather clear and yang
1.1. I don't understand why it needs to change now.

Robert Wilton: So the other concern that I have is this ambiguity that if you
don't return of value. That mean the device doesn't know about it

Andy Bierman: If it's not there, you're claiming conformance to. Then it is
using the default value no exceptions. So I think the part of the architecture
that's completely lacking is a concept of conformance for data stores. So I'm
reading a YANG module, I want to know what is a server that is conforming to
this model supposed to do. And you completely failed on providing that
information for data stores before we used to know this is candidate running
and startup there were only three data stores. There's no way to add new ones
like the operational data store which is now allowed. So really think it there
has to be something in the yang module that tells developers what the
conformance expectations are. And the defaults as is it could be considered
part of that. But the problems that I've been hearing about from customers with
operational data is how to make it more efficient. This has not been a fixed
yet. Because the problem with get is if I get an entire list while I'm getting
10,000 entries. So we've had to add operations that make it much more
responsive to iterate through a list. And of course you need to iterate through
a list without knowing the keys because operational data the keys change all
the time. So I think you really should focus more on efficiency because it
especially with you know large routers which you have a lot of the getting,
lots of operational data, it needs to be efficient.

David Lamparter: Sometimes libraries can't tell if it was a default

Robert Wilton: I think your suggestion is better to return a value even it's
the same as the default.

David Lamparter: I'm saying that if you want to signal this bit of information
whether the value is actually in use then you need to put that bit of
information somewhere. That isn't the existence of the value, because the
existence of the value is not something that you can reliably test for.

Angle Erikson: I don't think even the absence of the value doesn't really mean.
That the default is enforced, maybe some other protocol remove the default
value, and that's why it's not there.

Robert Wilton: the case we’re thinking of is if one of your demons has crashed
and it's not returning any data then effectively. That doesn't mean that those
values are now and turn into the default values. That just there's no data to
be returned there and either you hang the whole response or you've got to
compromise.

Ladislav Lhotka: I think semantics for defaults may differ in <operational>, so
it could be difficult use them

Robert Wilton: I think in terms operational we regard the default value, and
yang models being guiding to the reader rather than meaning anything else. So
rather than affecting the actual data returned.

Sue Hares: Confusion regarding description of the 'dynamic' identity ("except
derived identities")

Robert Wilton: I think is there might be a typo effectively what its meaning
here is the dynamic identity itself is probably more likely to be abstract and
that rather than returning that at your dynamic data store you derive from your
identity the right value.

David Lemparter: should put in metadata if something not in-use
Tim Carey: I think the problem with that is I think one of the reasons for the
the default value as stated by Andy was that you were trying to save space, so
if I'm sending metadata back must send the value back?

Phil Shafer: with-defaults was primarily to reflect variations in how
*configuration* (not state) was handled.  Less with respect to space savings.

Balazs Lengyel: different methods of handling before the the other method is
that if you have a default it gets there and you don't care any longer how it
got there. 3 different handling and I think if we have with defaults on get
data that would solve the capacity issue so why not handle that way

Phil Shafer: The operational data store gives actual, in-use values only.  If
not in-use, it's not returned.

Ladislav Lhotka: regarding templates, which drafts references, how are deletes
of unexpanded templates relate to validation

Robert Wilton: will need to consider handling templates

Balazs Lengyel: If we implement only part of the NMDA datastores (is that
allowed?)  How shall we indicate it? What compliance requirements exist for
these non-fully NMDA compliant implementations?

Robert Wilton: when you have a large change come in, will have see
inconsistencies in existing models which won't be present once have NMDA data
stores

Chris Hopps: if an interface is configured, but down, is it returned in
<operational>

Phil Shafer: That was a comment on operational. It's always intended that your
intended configuration in operational, you'll see what's in use, if it's not
being used you shouldn't see it.

Rick Taylor: confusion between 'dynamic' and 'learned'

Robert Wilton：This identity really means dynamic data store so maybe the name
of that identity should be dynamic data store all one of those dynamic data
stores. "Learned" is coming from a protocol that's not one of the configuration
protocols. And not through a dynamic datastore. So something like your BGP
peers, when they return values that override your configuration, that would be
marked as learned configuration.

Phil Shafer: idea is that dynamic data is inside the "ecosystem", whereas
'learned' is more from an external system (e.g.: DHCP).

Chris Hopps:  I have a suggestion on how to resolve the interstate interface
down State. One way: detect a failure by looking into operational state to see
if it changed; the other way, use a notification.

Jason Stern: How about the case if that line card is physically unplugged from
the router?

Robert Wilton: it be removed from applied configuration.

Lou Berger: how much time do you need to address these open issues?

Robert Wilton: don’t know yet...

Lou Berger: milestones publication request in Oct, which reflects a LC in
September...

Phil Shafer: important to keep current deadlines/targets

> 3   16:30  15  Title:  NMDA Guidelines
>                Presenter:  Robert Wilton
>                Draft: 
https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01

Ladislav Lhotka: In this example (slide 6), one interesting case is this router
ID. Because in the routing data model’s base feature that makes this router ID
available at the global level. But if this feature is off, it doesn't mean that
the router doesn’t have any ID. It only means that the ID be assigned
automatically. So it means that in this case some routers will have both outer
ID in configuration and in state, but some routers will have it only in state
data. But if we keep this if-feature on this router ID, we need to distinguish
it, if you want to have just one data node for both configurations data and
state data.

Robert Wilton: You can still get away with one node here, and the desire that
you look at it on the same path, and then resolve with your configuration.

Sue Hares: This can be set, I believe it operates in the way that is expected
in the BGP configuration whether it's unique variable? How it’s populated? Can
it be populated from the base?

Robert Wilton: If the origin from the base, origin='defaults', or you'd have
configured

Igor Bryskin: how I can see this data what is actually configured versus what
was intended to configure and has failed.

Robert Wilton:  You can't point one unless you create this duplicate separate
tree. But in many case you don't actually know that (intended). All you know is
the system's accepted the configuration will act on at some point.  What we're
proposing here will be consistent.

Andy Bierman: If someone want the keys for this list to be different in
operational state than config? I have one more key to add or they say the
operational state value leaf is a different value. Are we discouraging people
from that and forcing them to use the same keys everywhere? Or not expose a key
that they wanted to put in there? What's the guidelines for when the model is
not this simple?

Jabber: (11:07:22 AM) Eric Voit: If I can’t be heard, my question is: When do
the NMDA modeling guidelines take effect?  For example, when must drafts
entering WG last call match to this?

Jabber: (11:15:31 AM) LouBerger: @Eric V  WRT your question  - currently the AD
recommendations are in effect.  The WG has not yet agreed on its position

> 4   16:45  20  Title:  NMDA Q&A
>                Presenter:  Robert Wilton

[This Q&A was mixed into the above two presentations, and the slides were not
presented.]

> 5   17:05  15  Title:  BBF Update
>                Presenter:  William Lupton
>                Draft:

Benoit Claise: regarding NMDA, do you have any plans for updating your modules
accordingly?

William Lupton: We don't yet have a plan but will formulate one asap.  I expect
that we will follow the same guidance as is being given to other IETF working
groups

Lou Berger: We use the Q&A session(Today) to explain it.

Andy Bierman: does netconf-state (6022) really need to be updated?

Lou Berger: this needs to be discussed more

> Session 2:
> WEDNESDAY, July 19, 2017
> 1330-1500  Afternoon Session I
> Congress Hall I
> Audio stream:  http://ietf99streaming.dnsalias.net/ietf/ietf993.m3u
> YouTube: https://www.youtube.com/watch?v=kNfYz2HldFs
>
> 0   13:30  5  Title:  Intro & WG Status
>                Presenter:  Chairs

> 6   13:35  20  Title:  Schema Mount
>                Presenter:  Lada Lhotka
>                Draft: 
https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-06

Dhanendra Jain: How is this reference different from a bind a NI to an
interface.

Ladislav Lhotka: Every bind reference is bounded to a particular interface

Dhanendra Jain: Check that interface tree is not available.  It's really will
only for the context of any evaluation, such as when statement, or must
statement the inside the mount.  Your system get these interfaces.

Lada we added for the purpose of evaluation.
Balazs Lengyel: if we have nested mounts, can the nested mount reference the
parent's schema?

Ladislav Lhotka: Current it is not possible.

Lou Berger: You also have recursive support.

Ladislav Lhotka:  I don't think that it's very sensible to define many levels
of scheme amounts. We are addressing here is the network device model.

Lou Berger: Speaking as contributor to LNE and NI model, If you start at top an
bind an interface to an an LNE then into VRFs, you don't end up getting 2 step
references, you just need a single step.

Balazs Lengyel: If you have interfaces at base and mounted, then do you have
problems with the keys at multiple levels.

Ladislav Lhotka: Discussed this last time, xpath expression evaluation would
allow for both.  So there needs to be some warning that this shouldn't be done.

Lou Berger: This is an implementation time thing.  Down to implementation
choice.

Phil Shafer: If I mount 3 levels, can you get out of the parent to the ancestor
tree?

Ladislav Lhotka: one step one step up like in the schema hierarchy

Open Issue 1:

Acee Lindem: no doubt this would be useful. Call it a different name than
context node, perhaps parent reference instead.

Ladislav Lhotka: Terminology is in the context of Xpath.

Kent Watsen: Is option 1 the author’s preference.

Ladislav Lhotka: Yes

Kent/Ladislav Lhotka: We can take the issue to the mailing list (if no
objection, then option 1 will be selected).

Open Issue 2:

Robert Wilton: does Martin have the same option?

Ladislav Lhotka: yes. I believe that he agrees

Robert Wilton: slight preference for the extension

Balazs Lengyel: who controls what you can access from parent module?

Ladislav Lhotka: This is true.  If you do this, then the parent module has to
know what is going to be used in the parent schema.

Balazs Lengyel: This could be a good thing or a bad thing. It allows you to
control what you expose and modularity is good, on the other hand you have to
research…

Ladislav Lhotka: This moves the responsibility. Currently, it has an
implementation time feature, this would be when yang module be designed.

Lou Berger (as a contributor): I raised this, and sees a use case for this. 
Both authors pushed back hard on this.  This brings in design time mounts.  As
a contributor, I would really like to see it there, but as a user I see that it
as good enough (as the person who raised the issue initially).

Ladislav Lhotka: You can include it when you design a new model.

Lou Berger: Don't want to discuss how we do extensions.  We should be able to
discuss when we do design time mounts.  I think that this is a reasonable
approach.

Juergen Schoenwaelder: Why do you think that causes a problem with the YANG
language version?

Ladislav Lhotka: Clients might not need to know about the extension.  Would be
a problem if it understood the mount point but not parent reference extension.

Balazs Lengyel: General question: if you declare support for a YANG module then
you MUST support any extensions in that YANG module.  If you support this
module then you support all of them.  Asking YANG doctors to answer this.

Ladislav Lhotka: In this case, you can have these modules in yang library

Lou Berger: I think the answer is yes, we can confirm in the RFC.

Phil Shafer: It is a qualified yes.  Things like features may mean that you
never actually use it.

Kent Watsen: Asks WG if the doc is ready for last call.  [A reasonable show of
hands]

Kent Watsen: Is there a dependency on the YANG library work that has been
proposed in NETCONF.

Ladislav Lhotka: Currently, it have the dependency. We could use different
revisions of the same module.  All libraries used in the system should have a
single YANG library tree.

Lou Berger: Yes, OK to move forward?

Ladislav Lhotka: Depends on YANG library document.

Lou Berger: Still just an individual draft.

Lou Berger: As a chair, we shouldn't wait for an -00 individual draft, or even
WG doc.  Need to be faster moving forward with YANG modules.

> 7   13:55  10  Title:  YANG Tree Diagrams
>                Presenter:  Lou Berger
>                Draft: 
https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01

Robert Wilton:   x vs -x - seems confusing, not obvious enough...

Ladislav Lhotka: I think this is not possible. In general, if you have this
scheme amount references, it's really about instant, this tree describes the
schema. It really depends on the evaluation of the reference XPath expressions.
So it could happen not in the example because it's all the same.

Lou Berger: That's not something that you would see it at design-time. We do
believe that this is question from vendors that want to relay to customers what
the schema really looks like.

Ladislav Lhotka: If you use parent-reference YANG extension, it would be more
clear what is available and what isn't.

Lou Berger: May be forwarding looking and a future idea.  We will use it in LNE
examples.

Juergen Schoenwaelder: The interfaces at thingy can only be generated if I have
state information. So I can't get it out of the state information. Ladislav
Lhotka: Wouldn't expect to see in module definitions.

Balazs Lengyel: Are the top two lines (only used if I know the instance data).

Lou Berger: Only the MP (mount point) which would show up in from schema data.

Juergen Schoenwaelder: Should we be able to put comments in the tree?

Rick Taylor: Comment on comments.  Yes, add one now.

Ladislav Lhotka: Opposed.   Tree diagrams are normally generated by tools. Does
this mean that the comments need to be in YANG modules as well.  Also line
space is quite long.

Lou Berger: Send proposal on comments to list if there is interest.

Chris Hopps: New formatting for RFCs, do these get prettified.

Lou Berger: No idea.

Chris Hopps: Question is really about line wrapping.

Benoit Claise: Good to have a RFC, is there a commitment to update to this
format from tooling folks, e.g. pyang and YANG lint.

Lou Berger: Currently only change is adding "mp" for schema-mount

Juergen Schoenwaelder: Is the extensions state currently empty, what do you
plan to do?

Lou Berger: We haven’t discussed it yet.

Balazs Lengyel: Is it usage or definition of extensions that you are thinking
about.

Lou Berger: Usage.

> 8   14:05  15  Title:  Update on Routing Area WG YANG documents
>                Presenter:  Acee Lindem
>                Draft: 
https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-08 >                
       https://tools.ietf.org/html/draft-ietf-rtgwg-lne-model-03 >             
          https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03

Chris Hopps: Module tags need more time to bake.  Will try and push it forward.

Dean Bogdanovic: On tags, other areas would be useful.  Tags for YANG Catalog
and YANG library would be helpful.

Dean Bogdanovic: On L3VPN state, need to think about timestamping.

Lou Berger: This needs to be stated in the Rtgwg.

> 9   14:20  15  Title:  Interface Models update
>                Presenter:  Robert Wilton
>                Draft: 
https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-05 >               
        https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-02 > 
                     
https://tools.ietf.org/html/draft-wilton-netmod-interface-properties-00

Glen Parsons：Tag/second-tag you rename it? It need to discuss in IEEE, liaison
with us(IEEE?)

Robert Wilton: Sure.

Dean Bogdanovic:  The skeleton of the draft looks that it provides another
functionality that put in all the types and everything else what is needed.

Lou Berger: How many people think this is an interesting work, and need to do
in netmod WG? (A reasonable number)

Lou Berger: How many people read this draft? (Less than previous question)

Robert Wilton: can you fill in the IEEE comment from Glen Parsons?

> 10  14:35  10  Title:  Mounting YANG-Defined Information from Remote Datastore
>                Presenter:  Alex Clemm
>                Draft:  https://tools.ietf.org/html/draft-clemm-netmod-mount-06

Chris Hopps: Like a bind-mount.

Lou Berger:              Is there interest in this function in the working
group? (tepid)
                                    Interest in talking/learning more? (a few
                                    more)
Lou Berger: Doesn’t look like there is support in the room for this draft at
this time.  Next step is more discussion on the list for the WG to learn more.

> 11  14:45  15  Title:  YANG module for yangcatalog.org
>                Presenter:  Joe Clarke
>                Draft: 
https://tools.ietf.org/html/draft-clacla-netmod-model-catalog-00

Rick Taylor: why not try to standardize it?

Robert Wilton: we want to evolve it rapidly, but may bring it in if the
semantic-versioning draft takes off

Phil Shafer: no need to standardize because no interoperability requirement