Minutes IETF105: netmod
minutes-105-netmod-00

DRAFT IETF 105 Minutes

> Agenda for the NETMOD WG Session in IETF 105
> --------------------------------------------
>
> Two Sessions:  (back to back, different rooms)
>
>    Monday Afternoon
>    Session 1: 13:30-15:30        in Viger (2nd floor)
>    Session 2: 15:50-17:50        in Duluth (2nd floor)
>
> WG Chairs: (sorted by last name)
>
>   Lou Berger   (lberger at labn dot net)
>   Joel Jaeggli (joelja at bogus dot com
>   Kent Watsen  (kent plus ietf at watsen dot net)
>
> Available During Session:
>
>    Etherpad:      https://etherpad.ietf.org/p/notes-ietf-105-netmod
>    Slides:        https://datatracker.ietf.org/meeting/105/session/netmod
>    Meetecho:      http://www.meetecho.com/ietf105/netmod/
>    Jabber:        xmpp:netmod@jabber.ietf.org?join
>    Audio Stream:
>      - for Session 1: http://mp3.conf.meetecho.com/ietf/ietf1058.m3u
>      - for Session 2: http://mp3.conf.meetecho.com/ietf/ietf1052.m3u
>
> Available Post Session:
>
>    Recording:     https://www.ietf.org/audio/ietf105/
>    YouTube:
>      - for Session 1: https://www.youtube.com/watch?v=jf86dU5XHbI
>      - for Session 2: https://www.youtube.com/watch?v=9k7qggWAS5o
>
>
> Introduction
>   Chairs (10 minutes)
>   Session Intro & WG Status

 Action: chairs should lead discussions to close existing errata.

> Chartered Items:
>
>   Robert Wilton (0-20 minutes)
>   Resolve Potential Issues from Last Calls
>   https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-07
>   https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-05

Rob Wilton: should we include histogram stats now or do it in a seperate
document

Tim Carry: advice is a concern, dependable ranges would be better

Rob Wilton: Have standard sizes for non-jumbo frames

Joel Jaeggli: existing values have historical meanings but may not be tied to
specific specifications.  May end up with lots of different values.  Getting a
good list beyond what is listed seems very risky.  Better to stick with
non-jumbo list.

Vladimir Vassilev: Would be good to have input/output unicast/multicast
counters.  Would prefer to not add counters to this draft.

Rob: (polling WG)
Who thinks we should include histogram statistic information in this document?
(Very few) Who thinks we should *not* include histogram statistic information
in this document? (significantly more, but still not a big number) Who thinks
histogram statistic information should be added to a new document? (a few)

Rob: I'll coordinate with IEEE 802.3 on this topic and report back their view
on IETF standardizing

>   Balazs Lengyel (10 minutes)
>   YANG Instance Data File Format
>   https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-03

Lada: Would prefer metadata stored as module information
<lots of dicussion>

Lou: How many think should keep as is in document? <very few>
How many think informatin should be added to modules? <less>

Lou: Authors please raise this question on the list.

Balazs: Ready for last call

Joel: Will move to last call once resolve question on metadata

Lada: Current approach of using the new yang library seems very complex

Rob Wilton: Could list moudules more simply

Vladimir: the new yang library is very complex

>   Qin Wu (10 minutes)
>   Factory Default Setting
>   https://tools.ietf.org/html/draft-ietf-netmod-factory-default-02

Joe: Joe Clark.  Input on any bullet point or anyone okay?

Qin: Last one

Joe: Okay I don't have a input on the last one but I really don't like bullet
number two

Qin: okay

Joe: the way it's defined in the draft, I could have my device reboot if I set
this RPC, that as an operator feels squishy, I would rather these things be
more atomic, like I use the RPC to reset the config and then I might send
another RPC to reboot the device

Lou: if you reset the config, how will you send the RPC to reset the device?

Joe: okay, let me restate. I would rather there be some more definition around
this so that I know what is is necessarily going to happen, and  it might be
that I only want to factory reset the startup and then send an RPC to reboot
the device as an example.

Balazs: Belazs Lengyel, as a co-author.  About the last point that factory
default might contain security data, I think that's actually not a question
about the factory default datastore because the same data will be available in
<running> after reset so it's the responsibility of the data model to somehow
protect this the security critical items, and this should be the same in
<running> and <factory-default> datastore, so I don't see why this is specific
problem to this draft.

Kent: Kent as a contributor and also author of the keystore draft work that is
being discussed. So the actual data lives in <operational> but it would need to
be promoted to configuration in order to be referenced by configuration, and
it's shipped from manufacturing, it'd be ideal for to be in the
<factory-default> or, perhaps, <startup>.  But the problem <startup> is it can
be deleted thereafter, I mean it could be a choice, it's not a security issue,
though, because the if the data is hidden then it's hidden and thus not a
security issue, and the data is encrypted, then it is encrypted and thus not a
security issue.

Balazs: okay

Tim: Tim Carey. So, two points.  One, I kind of agree with the last speaker of
the the fact that you know the factory default I don't understand security
issue, because I would understand that when we reset something the factory
default the factory information is going to be used to populate the startup,
right, that's effectively what's happening.  To the other question about the
options, in other protocols that we've done this with, and we've done factory
resets for CPEs for going on 20 years now, right, and in a standard way we we
actually allow for the other things that you're talking about, cleaning up
files or restarting to node, particularly restarting a node, simply being
options that go into the RPC, so you just simply say, look I'm going to do a
factory reset, by the way restart this thing when you're done.

Lou: to answer the question, Tim, to answer your question of why it's a
security issue, I think something that's a little different here is this has to
be done completely remotely, and in many of the factory reset options that come
up equipment, you have to do it locally, you can't do it over your network
management, wait there's some that do it over network management, but there's
some systems that don't, and there's definitely security implications if
allowing you remote access to reset a device, a network device.

Tim: sure so even with you reset the network device, factory reset, again,
we've done this for billions, right, so it's not like this is new, right, so
the information that's put in the manufacturing store, right, is then...

Lou: I'm saying the RPC itself is a security issue.

Tim: oh, certainly, okay, I'm sorry, yes.

Dean: Dean Bogdanovic. TPM, in the trusted computing, you know, they're solving
those problems, and I know many hardware vendors are putting TPM and modules
inside their hardware, so that helps you know somehow solve some of those
problems.

Kent: as a contributor again.  As discussed in the keystore draft in the
NETCONF workging group, indeed that is where we're expecting the TPMs to be
used to protect the the keys shipped from manufacturing that's what was
discussed in this morning's presentation.

Dean: ok.

Rob: Rob Wilson. I was just going to add for the our RPCs, if there are
security concerns with that, surely NACM would cover, part of access control,
of the factory reset RPC, so that I think there is anything particularly
different there.

Andy (via Jabber, Joel read into the mic): Andy said "I agree that
system-restart RPC in ietf-system.yang should be augmented instead of a new RPC
that requires 2 steps"

Qin: for system restart, this is something we already discussed.  I'm not sure
whether we should do the argument from the system-restart

Joel: I'm not actually disagreeing with you, I'm just channeling.

Rob: Rob Wilton. I liked what Tim said. I think that made a lot sense to me,
that you just have an option to say, also wipe files and another option that
says restart the device, if that's that seems fairly easy to define, that if
you don't specify then the device isn't restarted.

*** ACTION: authors need to update from discussion and then Last Call.

>
>   Alex Clemm or Yingzhen Qu (10 minutes, likely remote)
>   Comparison of NMDA datastores
>   https://tools.ietf.org/html/draft-ietf-netmod-nmda-diff-02
>   Slides:
https://datatracker.ietf.org/doc/slides-105-netmod-sessb-comparison-of-nmda-datastoresdraft-ietf-netmod-nmda-diff-02/

Rob: Rob Wilton.  have a question that's not related to these (issues that Alex
presented) at all, so maybe I could raise that one

Kent: go ahead

Rob: so Alex looking the draft, I'm still not entirely sure the diff is doing
quite what I would look for. so you have an "all" option you can be turned on
or off and, if the "all" option is off you compare nodes that exist in both
datastores, so <intended> and <operational> is that right Alex: yes

Rob: and only the nodes that exist in both do you compare the value, and if the
"all" options on, it says among you you would do a diff against the full
contents of both datastore, so I think that would mean, in operation, you get
all the data backs or all the operational state back, or would you still apply
a filter so it only only "config true" items would come back?

Alex: the ideas, of course, is that you would only report differences back

Rob: yes yes but if you compared <running> or <intended> to <operational>, all
the "config false" data in <operational> is guaranteed to be different from
<running> because it doesn't exist in <running> so, all your statistics, for
example, all that all that data will never ever be in <running>, it is never
going to be there, would you automatically exclude that?

Alex: no, we would not automatically exclude that so it is basically up to the
client to specify and what it wants to have compared.

Rob: so I think that "all" option, if you compared any configuration datastore
to <operational>, it is going to give you back a lot more data than you're
interested in because it will give you back all <operational> data as well as
the applied configuration.

Alex: okay

Rob: I would be interested in having an option that just effectively compares
the "config true" nodes in <operational> against what is in <running> or
<intended>, but has all of those, you know, they're in exist in one or the
other.  I want to see configuration items that are in <running> but haven't yet
been applied, so maybe the line cards missing, and conversely I'd also like to
see configuration that I've removed from <running> but it still persists on the
system due to some issue or some error that, e.g., for some reason, my bgp peer
configuration hasn't been deleted, I'd like to see that, so I like an option
that filters the the "config true" part of <operational> against what's in
<intended> or <running>, if possible.

Alex: you're saying we need to have something between these two option because
right now we have either you include everything or you include or you exclude
data from the comparison that does not pertain to both, but you're saying that
you would want to have it restricted a little bit further, so a third optional

Rob: yeah between the two, though I question how useful the "all" option will
be, comparing <operational> to a configuration datastore I think that because
the amount of data will come back, by and large that's probably not what's
being looked for.

Alex: you also have a filter spec that you specify as well, so when you say
that all differences are returned that would only be if your filter spec is
empty or if your or if you're asking to compare the entire tree, which in
general might however not be the case. but I mean, of course, if you do this,
but it's true that everything everything will come back, but typically you
would have a filter spec as well

Rob: but if you consider, for example, say you're checking the configuration
for one interface then you might have three or four lines of interface
configuration, and in <operational> you'd have that plus hundreds of counters
another operational data and that would automatically always be returned,
because it will never ever be in <intended> or <running>, so I'll always be
reported as a difference, if you specify the "all" option

Alex: that is true, if you specifiy the "all" option

Rob: but my question is when is that useful?  does anyone really need that
case, is a useful case where that's useful data to return?

Alex: okay I think you're you're asking should we remove the "all" option and
just include another option instead

Rob: yes, that's my question.

Alex: okay so I don't have a strong opinion on the on the "all" option right
now, I do think definitely having the option to exclude it, that one certainly
is important if you want to have everything.  yeah I'm okay I don't have a use
case actually right now at the top of my head for this, so this is maybe a
question to ask the room.

Rob: Rob Shakir.  The only data point I can add is we didn't implement the
"all" option when we implemented this.   We didn't implement this draft, but
we've had a service doing this since 2015 I think and we don't have an "all"
option

Alex: okay

Kent (as chair): okay so that drained the my queue and we'll go back to going
over these points and asking the room for information.  First was the patch
format and I think the question was, given we have had an agreement that there
should only be one format that should be returned, the question is what should
that format be.  The current proposal is an augmentation to the patch format
and the question is if that is sufficient, or if there should be another
format, in particular something that may be called a YANG-diff format, instead
of augmenting patch, maybe we should define a format that's very specifically
customised for returning diffs.  Did I capture that correct, Alex?

Alex: yeah this is correct but bare my mind the there is no YANG-diff format
that has that has been proposed yet, we do think it can be done using the
augmentation of the patch format, but we could of course define it, but yeah
that is correct

Rob: Rob Wilton. I wouldn't define a diff format as part of this work if that's
to be done I'll do it as a separate RFC, I would say do patch format now but
hopefully designed in such a way that it could be extended to cover a different
format in future if that's feasible

Kent: at last time's meeting we concluded that there should only be one format.
 what you're saying is let's reopen and possibly support multiple formats?

Rob: I think if we're going to choose one format, choose the one we already
have, so rather define a new one so, if the jury concluded we only one one
format, then use yang patch, that seems fine

Kent: okay.  Objections?  Does anyone else have a comment about this?  As a
contributor, I do worry just a little bit about augmenting yang patch that the
patch format it just seems awkward to me, and I do think this will be the
important feature, and one that will be will be living with for a long time,
and I think that it would behove ourselves to ensure that we pick a format that
this ideal for this purpose, and in particular imagine us needing to extend the
format in the future, or maybe yang-patch changes in the future, and they would
be coupled in such a way that we don't get to do what want if they were
separated.

Rob: so I also don't mind if you want to define a diff format, again I still
wouldn't define it in this document, that is something that's better to defined
generically and reference it from this, if the proposal is to use a yang-diff
instead of yang-patch that also is fine, but it's going to slow down this work
though, if you do that I think by whatever time it takes to define a yang-diff

Kent: okay so I guess that's the question

Alex: well, I guess we have three questions, the other question is well to also
revert on the earlier question and if you want to allow for yang patch augment
it now and then maybe something different later

I can ask a question alright, say let's start with that because, if we are able
to support multiple formats, then we can let go the other remaining questions. 
that's the first question for the person, right, so we're going to ask two
questions first is for who supports and then the second would be for who does
not support.  So, for those who do support the idea of just returning a single
format, that there's no option for the client to specify the format please
raise their hand

Lou: I think the question you are asking is who supports restricting the return
to a single format.  So who would like only a single format question is who
wants to allow

Kent: right, okay, so the single format, please raise your hand.  There's very
few. Thank you.  Support a multiple formats?  and also a few but statistically
more a lot more, so that effectively reverts the decision that we had from last
time, and if we allow for multiple formats, and my objection for moving forward
with this format now is obviated, I no longer worry about it because I know it
can be fixed later, so then I think we don't need to ask any more questions. 
We could move forward with this format.

Rob: Rob Wilton. I just want to clarify, I support multiple formats, but I
restricted them to small set of them probably, limited to two

Kent: sure okay, they would presumably go through the working group and the
working group would only adopt the work if it was reasonable, It's
self-limiting.

Alex: well one question is how we would do that, practically, earlier we had a
flag that was allowed to specify the format and base is the preference for
format and if this is about the but if, you're saying we need to allow for
future formats, I'm not sure how we can say it's only this or one other formats
which has not been defined yet

Kent: okay great, so I'm moving on to the second bullet point then, should
parameter be included to control whether or not to include "origin" metadata
when <operational> is the comparison target?  So I know we all have to remember
everything that Alex said before, but hopefully that's clear again yes No.  So,
should a parameter be included, if you believe that a parameter should be
included to control whether or not the origin metadata should be returned,
please way to raise your hand. there's very few.  The option is that no
parameter is specified then, Alex, help me here, if no parameter specified is
the origin metadata automatically returned or not returned?

Alex: yeah well then just be returned by default

Kent: let me restart that, because I'm not sure if everyone was clear about
that, so if you think that when there's no parameter and origin metadata should
be returned by default, please raise your hand.  okay there's no one

Rob: Rob Wilton: Not all devices will necessarily support origin metadata, so
the question really is whether it's better to have that as an input parameter
such that you'd fail the request you can't support it, or whether you just
don't return it, if you don't have it, so that's why I prefer having parameter,
because then at least you know as a client whether I'm not going to get this
data.

Alex: okay I guess there's a good reason to do, okay that's a good point, so
this will be in favor of having a parameter to control it, in which case one
would expect it, and then we could have an explicit error if it's not
supported, then obviously the request will be denied.

Kent: Alex, you're agreeing with Rob.

Alex: yeah, I am agreeing with Rob yes

Kent: and as a contributor I agree as well, I think that it is a good idea. 
Third bullet point "comparison filter is defined using subtree and XPath as per
NETCONF.  Is there a requirement for the definition of filters related to
target resources per RESTCONF?  Okay, Alex, can go over this bullet point again?

Alex: well then, this is something that has been in the draft for awhile, so
basically the comparison filter that we use, the filter spec, well it's a
question many but include as part of the filter spec where we say  which part
of the datastore to include and this one basically is defined per  NETCONF, in
a NETCONF-ish way, using subtree and XPath, and the issue was brought up in the
past, about allowing a RESTCONF way of of defining that, of putting the
filters, where you put a different format for the filter spec.  If you look at
it so if you look at the RPC, this parameter is defined as essentially is a
subtree filter or XPath filter, these are the things you think that you can
have.

Kent: you're saying current definitions is that either a sub tree or an xpath
filter can be passed

Alex: yes

Kent: and the question is whether or not we should extend to support also a
third which would be mimicking RESTCONF like semantics.

Alex: right that was the issue in there yes

Kent: when I'm thinking about RESTCONF filters, they are, you know, the query
parameters, so there's "fields" for instance, would be one of them, is that
we're thinking?

Alex: yeah, on this particular item, I'm not exactly sure, I mean this was
brought up in the past, obviously even when we define it, we thought actually
that what we have, the filter specs, to be sufficient for what we need to
accomplish so from that perspective, as a contributor I don't see the need for
that, but it was brought up by the group before and we have listed it as an
item in the draft, so this is why we need to raise a question so if they are if
if people think we need a different format, we should discuss it.

Kent: so it's an RPC, not an action, correct?

Alex: this correct it is an RPC

Kent: the way RESTCONF works, for most part, is you specify the URL to the node
that you wish to operate on, the resource governing on which would in in
NETCONF parlance would be more like an action, as opposed to an RPC.  To the
extent that this is an RPC and then in RESTCONF terms that be in "/operations",
at a global level, and hence the RESTCONF query parameters would not make sense
in that context you would have to have something like what you're suggesting of
subtree or XPath filters, I don't believe the option exists, however, if we
wanted to support actions instead of RPCs, then we could have that
conversation.  Does anyone else have an opinion about this? I don't think this
is something pull the room we're gonna poll the rooms on, we're just discussing
it.  Does anyone wants to comment on it?  (none)

Kent: All right, Alex, I think we should take this one to the list, it's pretty
complicated and some examples would help.

Alex: all right yeah or maybe if nobody's coming forward with the reason why
subtree next time would not be sufficient then we probably just can close this
issue

Kent: sure, and we may actually raise the question why to support both subtree
and XPath

Alex: okay, that's a I guess that is a six second question

Kent: because in NETCONF, subtree is mandatory to implement.  Of course, if
you're if you're a RESTCONF server and you're not implementing NETCONF, that
might be unfortunate you may not want it

Kent: okay, lastly and the question is do we add a performance considerations
section, this is Tim's thing.  Tim, did you want to walk us through exactly
what it was you raised on the list?  He's approaching the mic...

Tim Carey:  So when we read the draft, there were some concerns, and in terms
of an implementation because we have some very constrained servers, right, that
if I was given a request to do a diff on some datastores where I don't have the
compute resources to return the information being requested, the question came
back was what do we do, what is the appropriate response that we should give
back, should we curtail what we have and just provide what we have, should we
give them a, you know, thumb our nose to them or not, whatever it's supposed to
be, we'd like to have that response certainly documented of what happens if we
can't fulfill the request, right, and Alex  said we've already created some of
this in the Security Considerations section, but in reality we probably do need
some type of you know performance piece to say hey look you know if you're if
you can't fulfill the request, you should do this type of things for these
types of behaviors that you can't fulfill

Alex: well yeah there was an underlying question on this is as well but one
thing was I mean obviously if you cannot fulfill the request, you can always
just decline it, deny it, but I guess the other question relies to do you want
to have some kind of throttling operation or so you can have only so many
requests per time unit or what have you

Tim: we weren't worried so much about a metoring or a throttling aspect of it,
if someone else might be, we were just saying look you know we we might not
necessarily be able to you know meet the meet meet the request coming in, what
we wanted was was that we wanted this the RFC to specify the behavior,
specifically, so that people that are implementing this will know you know what
to do.

Alex: sure yeah I think what you're asking for is mostly tutorial item as well,
so let's just add it, I think if we can get clearer, if it clarifies  things, 
why not do it, I would suggest we just added for the next revision.

Kent: according to my clock were out it we're almost have time, but Lou's says
we're out of time, still, I  don't fully understand why it is that aserver
wouldn't be able to fulfill the request, so let's take a this to on the mailing
list

> Design Team Items:
>
>   Robert Wilton and Joe Clark (50 minutes)
>   NETMOD Versioning Design Team Update
>   https://tools.ietf.org/html/draft-ietf-netmod-yang-versioning-reqs-01
>   https://tools.ietf.org/html/draft-verdt-netmod-yang-solutions-01
>   https://tools.ietf.org/html/draft-verdt-netmod-yang-module-versioning-00
>   Slides:
https://datatracker.ietf.org/doc/slides-105-netmod-sessb-netmod-versioning-design-team-update/
[+0:02] <Joe Clark presenting>

Lou Berger: With respect to requirements, you have requirements listed in
multiple documents. Please keep them in one place.

Benoit Claise: Once requirements are documented, can we agree not to revisit
them.

Joel Jaeggli: Yes, once they are agreed to.

Lou Berger: This is also why they should be listed in one place, if listed in
multiple places need to discuss and agree to all each time they are
updated/changes.

Joe Clark: It is our intent that these requirements now become fixed

<Robert Wilton presenting, slide 6 [00:08]>

Lou Berger: (Slide 10) can you talk about if there's any significance that the
naming of the documents (3 /4 vs 1/2)?

Robert Wilton: The first two are output of the design team, the second two are
drafts I wrote. It's not because the design team doesn't align necessarily with
that direction. The plan is for the design team to work on all, and we can
update the names accordingly.

Lou Berger: the name doesn't matter so much as it's a file name, but whether we
have a complete solution from the design team or a partial solution does matter
and we (the chairs) are really hoping to get a complete solution from the
design team.

Dean Bogdanovic: (slide 13) on a router you may have dependencies between
packages? How do you handle conflicts?

Robert Wilton: At the time you combine those two packages together into a into
a combined package you have any resolve any conflicting module dependencies
explicitly say how they're resolved.

Lou Berger: What does the design team want from the working group today?

Robert Wilton: that the working group see that the DT is headed in the right
direction and are headed on the right approach.

Dean Bogdanovic: Handling the dependencies between packages is going to be
important.

Doug Hubler: The semantic version sounds great. I was always wondering why it
didn't start out that way. When you're talking about visualizing the difference
between schemas, would it be the resolve schema once you've resolved all the
groups, because usually that's what consumers usually are mentally visualize or
is it visualizing back to YANG groups.

Robert Wilton: I think both are necessary.

<Balazs Lengyel Slide 17, [00:31]>

Kent Watsen: (slide 25) Would it stop at a module revision and has NBC changes

Balazs Lengyel: no, because most of the time the NBC changes don't impact the
import

Robert Wilton: we think that this is the right balance being not too strict
because otherwise if you limit it it's more likely than actually but I said
you're not going to be impacted you start update your module any way so we
think it's better to be better than to be too strict performed okay

Kent Watsen: You may to put brackets or limits into how much future you want to
support automatically.

Kent Watsen: (WRT slide 24)  he two feature statements that you're creating
here is this what I understand to be possible extensions to core yang language?

Balazs Lengyel: yes

Kent Watsen: (WRT slide 28)  I like the idea of having an ability to specify
whether or not the server actually  complies or not that being the case why
aren't these MUSTs

Balazs Lengyel: for compatibility

Lou Berger: Since you're doing extensions you can change the rules for
implementations that implement that extension. So you can say if you implement
this extension you MUST do these things. It's probably worth reducing the
number of options, so in the case where you have an extension think about
making things more MUSTs than SHOULDs.

Balazs Lengyel: Martin be account held previous meetings a very strong opinion
that we need to indicate in the yang library whether these first two rules are
followed

Robert Wilton: I have a question whether the second point here couldn't be
covered in an errata

Lou Berger: Would need to see the text to judge if an errata or should be in a
BIS

Joel Jeaggli: Submit the errata and then we can debate it.

JP Landry: How is branching handled?

Balazs Lengyel: This is covered separately.  For example the Semver approach
has limited branching support

Charles Eckle: Are you applying meaning or semantics to the revision number
part.

Balazs Lengyel:  This draft just carries the label.  The SemVer draft does.

Robert Wilton: we allow for different versioning schemes

<Robert Wilton, slide 32, [00:54]>

Robert Wilton: Will continue to work the drafts until have a complete solution
to move forward for working group adoption.

> Non-Chartered Items:  (Some of these may overflow to 2nd session)
>
>   Robert Wilton (15 minutes)
>   YANG Packages
>   https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-01
>   Slides:
https://datatracker.ietf.org/doc/slides-105-netmod-sessb-versioning-yang-schema-draft-rwilton-netmod-yang-packages-01/
[+0:55]

Kent Watsen: with respect to slide 2 you said that if you support the package
you're obliged to implement all the package versions as they are , does this
also include features and/or deviations ?

Robert Wilton: yes, but you can also implement your own packages and modules
that may include additional features and deviations

Robert Wilton: Does anyone have thoughts with respect to slide 6?

Charles Eckle: What about the version of the package? would it be ordered? Is
it implied if  the version of the package increases the version also increases?

Robert Wilton:  I think they would be entirely decoupled , i.e., there's no
correspondence between the package version number and the version numbers
inside other than other than the semantic change the package so if you've made
a change to the what¡¯s included in that package this numbers compatible
because you've changed your numbers compared to a module or you've down read
the module that would be like a non-backwards would change to that package
definition so it would go from 1 0 0 to 2 0 0 if you were doing a down ref.

Charles Eckle: Yes, was thinking of a case where the package number increases,
but the included module has a lower number

Reshad Rahman: How do you handle the conflict when on package includes another
and the versions differ?

Robert Wilton:  yes so you see effectively say on the config resolution I want
to have this particular version  and  identify which specific import you are
overriding

Lou Berger: Can you elaborate either on your view or the design team view of
why you want to allow multiple ways to identify versions?

Rob Wilton: so in terms of the modular version the reason for doing that is
because that's what some people wanted. they thought that they don't like the
yang semver scheme because they find it too restrictive. Other people think we
just use the standard Semver.  So for module level versioning want to allow for
both/any. At the package level, if have that flexibility for modules will need
the same for packages.

Lou Berger: as we progress the work from the design team to the WG to the IESG,
we want to consider if there is good reason to allow multiple options, and if
not decide on the cost of the flexibility.

Xufeng Liu: question on conflict resolution mentioned on slide 5,. how is it
resolved?

Robert Wilton: if for example this was importing two modules to the two
different packages and one of them he was using IETF types version 1 0 0 and up
was using IETF types 1 0 1 then this package as well as doing the import would
say I'm going to use IETF 1 0 1 as my version for this package

Xufeng Liu: What abaout when two packages include different modules, each of
which include conflicting versions?

Robert Wilton: When there's that level of conflict need to come up with
non-conflicting packages. Recall that a server only can implement a single
module.

Kent Watsen: it's possible to have different netconf servers and support
different module sets per server

Balazs Lengyel: only a single version of a module can be supported at the
current time.

<next presentation relates to this question>

>   Reshad Rahman (15 minutes)
>   YANG Schema Version Selection
>   https://tools.ietf.org/html/draft-wilton-netmod-yang-ver-selection-00
> Slides:
https://datatracker.ietf.org/doc/slides-105-netmod-sessb-schema-version-selection-draft-wilton-netmod-yang-ver-selection-00/
[+1:13]

Lou Berger: (with respect to including this document as part of the design team
work)  don't feel obligated to rename it if you want to rename it that's fine
too.

Kent Watsen: do you have to call out protocols by name (see slide 6)?

Reshad Rahman: This is top allow differences in the protocols

Robert Wilton: Kent do you have a suggestion based on your experience with the
keystore draft?

Kent Watsen:  I was leading up to it I was looking at the port and I was
wondering what the intention for that port was and why wouldn't we be using the
the appropriate client server drafts from netconf?

Robert Wilton: that works.  This draft might end up in netconf.

>   Michael Wang (10 minutes)
>   A YANG Data model for Policy based Event Management
>   https://tools.ietf.org/html/draft-wwx-netmod-event-yang-02
>   Slides:
https://datatracker.ietf.org/doc/slides-105-netmod-a-yang-data-model-for-policy-based-event-management/
[+1:19]

Tim Carey: What is the relationship of this document with the routing policy
document?

Michael Wang: This work has broad scope, for example service assurance. We want
to define the more generic model.

Tim Carey: if this is just a generalization of routing policy, there may be
concerning overlap

Acee Lindem: (author of the routing policy draft) this is more a data plane
document, while the routing policy document is control plane. So no overlap.

Qin Wu: this is really about automating actions based on conditions that may
occur

Tim Carey: is this data plane or control plane

Qin Wu: this is management and data plane

Benoit Claise: This came out of the now closed SUPA working group

Joel: How many have read (a few)
       How many interested in topic? (more)
       How many interested in working on this topic? (a reasonable number)
       Who thinks we should be doing this somewhere else or not at all (no one)
       Who is interest in working on this, but is not already an author? (one,
       partial)
Will probably take adoption to the list.

>   Qun Wu for Ran Tao (10 minutes, remote or Qin)
>   NMDA Base Notification for Intent based configuration update
>   https://tools.ietf.org/html/draft-wu-netmod-base-notification-nmda-03
> Slides:
https://datatracker.ietf.org/doc/slides-105-netmod-sessb-nmda-base-notification-for-intent-based-configuration-update/
[+1:30]

Joel Jaeggli:  How many have read any version of this draft? (a few)
    Would anyone be willing to state their opinion of if this work is worth
    progressing?

Robert Wilton: Not sure.  It might be really hard to implement this draft. It
might just be better to have the operator monitor operational state of the
device.

Tim Carrey:  Seems like this problem is usually solved via status.   I was
struggling with what we wanted to produce notifications for.  I don't know if
this is realistic. There are other way to do it.

Joel Jaeggli: I think we need to see interest in this topic on the list.
Without that we don't seem to have the interest to work on this.

> List discussion
>  Qin Wu
>  NMDA Protocol Transition Issue Discussion
>  https://mailarchive.ietf.org/arch/msg/netmod/CYMK1cdLp5byiAkwDjaBngcTDQo
> Slides
https://datatracker.ietf.org/meeting/105/materials/slides-105-netmod-sessb-nmda-protocol-transition-issue-discussion-03
[+1:43]

Robert Wilton: (Open issues slide) I think it it is option 2. I think there are
was through this, perhaps without more standards options.

Qin Wu: yes, but some modules are not including the state tree, what should we
do?

Robert Wilton: given the derivative nature of the state module, they logically
exist even when not included in the draft/rfc.

Kent Watsen: You agree that there's an NDA a transition period, which is what
we're in now.  Do you have an example of a real issue?

Qin Wu: yes tags

Kent Watsen: That was discussed on list.

Qin Wu: but this module should follow the standard (convention)

Lou Berger: If there are other modules that don't have -state, but should,
these need to be fixed and perhaps blocked by the IESG.

Tim Carey: There are other organizations that have this same problem. We should
be consistent and provide guidence to industry.

Kent Watsen: We need to discuss on list, including if we should have any
Liaisons.