Subject: [Netconf] Summary and AIs from IETF-100 meeting

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 27 Nov 2017 15:27:06 -0800

Dear NETCONF WG,
 
Below is the NETCONF WG session summary and AIs that were taken from the IETF 100 meeting.
 
This e-mail verifies the discussion that took place in the room. Barring any strong objection, the AIs identified in this summary will be acted upon.
 
The NETCONF session took place on Thursday, November 16, 2017, between 15:50-17:50 Singapore Time.
 
The final notes from the meeting (once posted) will be available at:
https://datatracker.ietf.org/doc/minutes-99-netconf/ <https://datatracker.ietf.org/doc/minutes-100-netconf/>
 
rfc6536bis received comments in IESG review. Some last minute updates are being provided to address those comments, and once approved will allow the document to go towards publication. AI for authors to post updated draft before Benoit submits it for publication.
NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to support features like licensing, and semantic versioning. It also needs to address some bugs. Authors believe the document should be ready for WGLC by end of this year. AI for authors to provide updated draft before the three set of drafts are submitted for LC.
Zerotouch draft went through LC. It received comments during that period, which the author will address. Author believes that once the document is ready, it can be forwarded for publication, currently planned for December. AI for author to provide updated draft.
Keystore draft needs to be updated for issues raised in WGLC and discussion on the mailing list. AI for author(s) to provide updated drafts before LC can be re-initiated.
SSH/TLS NETCONF/RESTCONF Client Server Models also needs updates based on changes in the Keystore draft.  AI for author(s) to provide updated drafts before LC will be re-initated. 
YANG Push, Subscribed notifications and NETCONF notification drafts need updates based on discussion in the meeting and on the list. There are still outstanding questions on whether NETCONF notifications draft is needed or its contents can be folded into subscribed-notifications draft.  All these issues need to be discussed and resolved on the mailing list. Co-chairs will initiate WGLC once the issues are resolved. AI for authors to close on open issues and post updated draft. 
Notification Message Headers and Bundles and Restconf notifications - These two drafts will be considered for WGLC later. No AI.
UDP Pub Channel draft needs more discussion on the mailing list. A milestone will be added to the NETCONF WG milestones. No other AI planned at this time.
Cheers

Mahesh (and Kent)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Nov 2017 01:00:00 +0100

On Mon, Nov 27, 2017 at 03:27:06PM -0800, Mahesh Jethanandani wrote:

> NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to
> support features like licensing, and semantic versioning.

I do not know what this means. (The goal of the NMDA work is to
support NMDA - focus is good thing. Perhaps the minutes will some shed
light on what this AI means but the minutes are not out yet.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 28 Nov 2017 00:34:15 +0000

Hi,

One other action / question concerns WG adoption of draft-clemm-netconf-nmda-diff-01<https://datatracker.ietf.org/doc/draft-clemm-netconf-nmda-diff/> (Discrepancy detection between NMDA datastores).
The draft received considerable support when the question was asked in the room, but one question that was asked concerns whether this should be in Netconf or perhaps in Netmod instead.  Hence, cc'ing Lou and netmod.

The reason we put this into Netconf concerns the fact that this really defines an RPC, i.e. operations to facilitate interacting with NMDA-compliant servers.  It complements the RESTCONF and NETCONF operations, and the NMDA-extensions to those are also placed in the Netconf WG.  This seemed like another natural extension.  The draft does not really define a traditional YANG data model per se that would be used to manage something, therefore it simply did not occur to us to place it into Netmod, although I can see how one might make a case for that as well.

So, from our (coauthors) perspective, for the stated reasons, perhaps slight preference for Netconf, but really either one (Netconf or Netmod) is fine.  One thing we would not want to do is slow this effort down; since this was presented in Netconf, not in Netmod, if we were moved into Netmod it would hopefully not mean having to go back to square 1.

Thoughts?
--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Monday, November 27, 2017 3:27 PM
To: netconf <[email-masked]>
Subject: [Netconf] Summary and AIs from IETF-100 meeting

Dear NETCONF WG,

The final notes from the meeting (once posted) will be available at:
https://datatracker.ietf.org/doc/minutes-99-netconf/<https://datatracker.ietf.org/doc/minutes-100-netconf/>

  *   rfc6536bis received comments in IESG review. Some last minute updates are being provided to address those comments, and once approved will allow the document to go towards publication. AI for authors to post updated draft before Benoit submits it for publication.
  *   NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to support features like licensing, and semantic versioning. It also needs to address some bugs. Authors believe the document should be ready for WGLC by end of this year. AI for authors to provide updated draft before the three set of drafts are submitted for LC.
  *   Zerotouch draft went through LC. It received comments during that period, which the author will address. Author believes that once the document is ready, it can be forwarded for publication, currently planned for December. AI for author to provide updated draft.
  *   Keystore draft needs to be updated for issues raised in WGLC and discussion on the mailing list. AI for author(s) to provide updated drafts before LC can be re-initiated.
  *   SSH/TLS NETCONF/RESTCONF Client Server Models also needs updates based on changes in the Keystore draft.  AI for author(s) to provide updated drafts before LC will be re-initated.
  *   YANG Push, Subscribed notifications and NETCONF notification drafts need updates based on discussion in the meeting and on the list. There are still outstanding questions on whether NETCONF notifications draft is needed or its contents can be folded into subscribed-notifications draft.  All these issues need to be discussed and resolved on the mailing list. Co-chairs will initiate WGLC once the issues are resolved. AI for authors to close on open issues and post updated draft.
  *   Notification Message Headers and Bundles and Restconf notifications - These two drafts will be considered for WGLC later. No AI.
  *   UDP Pub Channel draft needs more discussion on the mailing list. A milestone will be added to the NETCONF WG milestones. No other AI planned at this time.
Cheers

Mahesh (and Kent)

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Nov 2017 16:35:46 -0800

> light on what this AI means but the minutes are not out yet.)
+1

Someday we might learn to use the YANG augment-stmt, but looks like not
today ;-)

> /js

Andy

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 27 Nov 2017 16:45:47 -0800

Juergen,

> On Nov 27, 2017, at 4:00 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I think there was some confusion around the naming and scope of the three “NMDA” drafts. The YANG Library draft is named as a rfc7895bis draft, while the other two are named nmda-netconf and nmda-restconf drafts. In addition, nothing in the abstract and the introduction of the rfc7895bis seems to imply that the only focus of the draft is NMDA. The other two drafts call that out explicitly. 

As a -bis draft, questions around what else makes sense. So questions around whether YANG Library will support the concept of licensing impacting what models are advertised and supported, and whether semantic versioning should be part of the YANG Library were raised. Do you disagree?

> /js

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Nov 2017 07:27:34 +0100

> As a -bis draft, questions around what else makes sense. So questions around whether YANG Library will support the concept of licensing impacting what models are advertised and supported, and wheth…

Seriously? The scope of work is defined by how an I-D is named? The
charter says:

  6. Based on the revised datastore concept work in NETMOD, provide a
     revision for the NETCONF and RESTCONF protocols and the used
     datastore framework.

And there were discussions leading to this charter text.

That said, I have no clue what 'licensing support' means or what
changes are needed to do 'semantic versioning' or even that there is
agreement to do 'semantic versioning'. (I personally believe semantic
versioning requires an new version of YANG since core rules of YANG,
e.g., how the import statement works, are needed.)

If we make the NMDA updates of NC and RC a moving target by putting
other things that come up into the document then we can be sure that
the update takes 3 years. I strongly prefer to scope the updates to
NMDA support with the goal to deliver soon (dec 2017 says the
milestone - but then what do milestones mean in a world where scope is
derived from I-D filenames).

/js

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 28 Nov 2017 14:17:41 +0100

Hello Jürgen,

a few observations inline:

> And there were discussions leading to this charter text.

I am not surprised that a subset of attendees expects that the title of 
a document refers to its content. Given that this is a bis in accord 
with the new charter this disconnect can probably not be completely 
avoided, but I am puzzled by your strong reaction, because:

a) given that the acronym NMDA is only used in the Introduction and only 
implicitly introduced there by reference of 
I-D.ietf-netmod-revised-datastores (which of course provides the 
resolved acronym by its title) and given that it is also never actually 
elaborated on even a bit anywhere in the document (there are a lot of 
terms such as NMDA-compatible, NMDA-supporting and NMDA-aware, but no 
further semantics are provided), I think - as a reader - it is totally 
okay to be confused here, and

b) just elaborating on what NMDA means in a nutshell and how it 
contributes to the solution this draft provides (and correspondingly, 
how it solves a problem) probably addresses this small issue?

I.e. just importing ietf-datastores in the module and using the acronym 
in an arcane way a few times probably does not provide enough context to 
compose a comprehensive document.

> derived from I-D filenames).

This seems to be an unnecessary jab that has nothing to do with the 
actual topics raised by Mahesh, which were:

- YANG Library will support the concept of licensing impacting what 
models are advertised and supported
- semantic versioning should be part of the YANG Library

Which, btw, I also am not sure about how and where that came up and what 
it means. In consequence - as Jürgen - I am curious to see the minutes.

> /js

Viele Grüße,

Henk

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 28 Nov 2017 14:36:58 +0100 (CET)

Mahesh Jethanandani <[email-masked]> wrote:
> Juergen,
> 
> > On Nov 27, 2017, at 4:00 PM, Juergen Schoenwaelder
> > <[email-masked]> wrote:
> > 
> I think there was some confusion around the naming and scope of the
> three “NMDA” drafts. The YANG Library draft is named as a rfc7895bis
> draft, while the other two are named nmda-netconf and nmda-restconf
> drafts.

This is b/c rfc7895bis provides a new YANG Library; it obsoletes RFC 7895
(if approved).

> In addition, nothing in the abstract and the introduction of
> the rfc7895bis seems to imply that the only focus of the draft is
> NMDA.

But NMDA is *not* the only focus of this document!  The draft has this
text in the Introduction:

   This document defines a YANG module that can be used to provide this
   informaton, in a way that is compatible with the NMDA
   [I-D.ietf-netmod-revised-datastores], but that is also backwards
   compatible with the "YANG Module Library" YANG module defined in
   [RFC7895].

which I believe is accurate.

> As a -bis draft, questions around what else makes sense. So questions
> around whether YANG Library will support the concept of licensing
> impacting what models are advertised and supported, and whether
> semantic versioning should be part of the YANG Library were raised.

Both these things are new issues, documented in individual drafts.  I
don't think we should postpone the publication of 7895bis until these
drafts are ready.  It is not even clear what the technical solution
around these issues will be, and if it can be solved in YANG library
or even if changes to YANG library are required.

/martin

> Do
> you disagree?

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Nov 2017 10:02:15 -0800

On Tue, Nov 28, 2017 at 5:17 AM, Henk Birkholz <
[email-masked]> wrote:

>>> On Nov 27, 2017, at 4:00 PM, Juergen Schoenwaelder <
>>> three “NMDA” drafts. The YANG Library draft is named as a rfc7895bis draft,
>>> while the other two are named nmda-netconf and nmda-restconf drafts. In
>>> addition, nothing in the abstract and the introduction of the rfc7895bis
>>> seems to imply that the only focus of the draft is NMDA. The other two
>>> drafts call that out explicitly.
>>>
>>>

My understanding is that a bis draft is intended to replace the identified
RFC.
Since NETCONF and RESTCONF are not replaced by the NMDA extensions,
they should not be named bis.

>>> around whether YANG Library will support the concept of licensing impacting
>>> what models are advertised and supported, and whether semantic versioning
>>> should be part of the YANG Library were raised. Do you disagree?
>>>
>>>
> I am not surprised that a subset of attendees expects that the title of a
> document refers to its content. Given that this is a bis in accord with the
> new charter this disconnect can probably not be completely avoided, but I
> am puzzled by your strong reaction, because:
>
> implicitly introduced there by reference of I-D.ietf-netmod-revised-datastores
> (which of course provides the resolved acronym by its title) and given that
> it is also never actually elaborated on even a bit anywhere in the document
> (there are a lot of terms such as NMDA-compatible, NMDA-supporting and
> NMDA-aware, but no further semantics are provided), I think - as a reader -
> it is totally okay to be confused here, and
>
> contributes to the solution this draft provides (and correspondingly, how
> it solves a problem) probably addresses this small issue?
>
> I.e. just importing ietf-datastores in the module and using the acronym in
> an arcane way a few times probably does not provide enough context to

Is there a draft proposing some license management feature?
I would support the ability to report "mods-available" and "mods-enabled"
(like Apache2).
Not all servers are monolithic firmware with no ability to load or unload
modules
at run-time.  The reason a module is available or unavailable is not
important to the YANG library .

The semver stuff is more interesting to opensource projects than IETF
document readers.
With an IETF YANG module, there are often releases that are not intended to
be implemented,
just reviewed.  Tracking the semantic versioning through the
work-in-progress phase doesn't
seem that useful. Tracking RFC to RFC seems more useful. I do not object to
adding a semver leaf
to the module entry.

Andy

> This seems to be an unnecessary jab that has nothing to do with the actual
> topics raised by Mahesh, which were:
>
> - YANG Library will support the concept of licensing impacting what models
> are advertised and supported

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 28 Nov 2017 10:55:40 -0800

> On Nov 28, 2017, at 5:36 AM, Martin Bjorklund <[email-masked]> wrote:
> 

I am not disagreeing with you. All I am doing is recording the discussion that happened in the meeting. And for the record, here are some notes from the meeting:

Benoit: Will the module have the capability to support modules that are dependent on things like license or presence of line cards. How to export from a server all potential modules? E.g. licensing might allow for additional modules
   Rob: No, this is not possible with the current version but the next version, about to be presented, would be capable of doing this.
   Kent: Refering to yesterday's discussion in NETMOD, would this be possible to support semver (semantic versioning), don't want to hold up this work, but thinking of flexibity for the future.
   Rob: Unclear even with semantic versioning whether a device is allowed to report multiple revisions of a module.
   Balazs; Each semver version should have one date based version, so that semver would be just an additional leaf in here in addition to the version field (date).

And there was no objection in the room about whether this should not be considered in scope. If the authors disagree, then I am glad we are having this discussion.

Cheers.

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 28 Nov 2017 11:02:55 -0800

> On Nov 28, 2017, at 5:17 AM, Henk Birkholz <[email-masked]> wrote:
> 
> This seems to be an unnecessary jab that has nothing to do with the actual topics raised by Mahesh, which were:
> 
> - YANG Library will support the concept of licensing impacting what models are advertised and supported

I do not think the minutes are going to tell you anymore about the requirement. So let me take a stab at what I think the requirement is. 

YANG Library currently compiles a list of modules (and sub-modules) that are supported by the device. The same device might also support the concept of licensing, where the license controls whether the feature can be enabled on the device, e.g. BGP. The server has the ability to support BGP as a feature (the software exists), but the customer has not bought a license for the BGP feature. What should the server do under the circumstances? Should it advertise BGP module, and have the request from the client fail? Or should there another flag, either in the YANG Library or some other module that informs the client that although the device is capable of supporting BGP, it cannot because it lacks the license.

A similar scenario exists with YANG modules that support a particular line card, and that line card is hot pluggable. What should the YANG library do for modules that it advertises, but the line card for that module may or may not exist in the system?

> - semantic versioning should be part of the YANG Library

The requirement here is whether semantic versioning can be supported in the YANG library in addition to the current version, which is a date. Details on how it relates to YANG Library should be brought up on the list, preferably on a new thread.

> 
> Which, btw, I also am not sure about how and where that came up and what it means. In consequence - as Jürgen - I am curious to see the minutes.

Thanks to Robert for updating the rough minutes. If anyone disagrees with what is recorded in the rough notes, please listen to the recording here <https://www.ietf.org/audio/ietf100/> and update the rough notes. They will be published as official minutes.

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Nov 2017 09:57:45 +0100

Mahesh,

so do I understand correctly that all this is about yang library and
has nothing to do with the NMDA update for RC and NC? This would
already help reducing my level of surprise.

Concerning licensing: A functionality that does not exist in the
server does not exist in the server, whatever the reason is. In the
future, there may be a standard YANG model that allows to configure
(enable/disable) functionality within a modular NC/RC server. So far,
I have not seen a proposal for this and hence I consider this topic
not ready for any WG action.

Concerning missing hardware: The approach of the interfaces model is
to support provisioning of interface configuration for non-existing
interfaces. Hence, if a server can configure say ATM line cards, then
the server should announce support for the ATM specific YANG modules
independently of the question whether ATM line cards are currently
present. To find out which hardware is present at a specific point in
time, consult the ietf-hardware model. I do not see why a change to
yang library would be needed to deal with missing hardware nor do I
recall what the proposed edits were.

Yes, from the SNMP world I know that sometimes support for specific
modules comes with the firmware of a piece of hardware but the NC/RC
design never went into the details of modular servers like SNMP did
with standards for subagent technologies etc. In the YANG world, this
is all entirely implementation specific and frankly I would not open
this can of worms. If the presence of some hardware enables server
functionality (or a license that is installed), then this may lead to
an update of the content of the yang library, like a restart of a
NC/RC server may do. I do not see which technical change would be
needed.

The bottom line is that without concrete actionable proposals, we
should not delay the finishing of NMDA work. And as Andy says, things
that can be done with augmentations are good to do with augmentations.

/js

---

From: "Mehmet Ersue" <[email-masked]>
Date: Wed, 29 Nov 2017 13:13:32 +0100

Hi Mahesh, All,

I believe the aim of the WG should be to fulfil the approved charter as soon
as possible.
The WG for sure can decide to adjust the charter if an extension is
necessary, however adding new topics with unclear solutions is
counterproductive with the overall goal to publish rapidly. 

BTW the notes from the meeting do not count much if people disagree on the
maillist.

Mehmet

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Wednesday, November 29, 2017 9:58 AM
> To: Mahesh Jethanandani <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
> 
> Mahesh,
> 
> so do I understand correctly that all this is about yang library and has
nothing
> to do with the NMDA update for RC and NC? This would already help
> reducing my level of surprise.
> 
> Concerning licensing: A functionality that does not exist in the server
does
> not exist in the server, whatever the reason is. In the future, there may
be a
> standard YANG model that allows to configure
> (enable/disable) functionality within a modular NC/RC server. So far, I
have
> not seen a proposal for this and hence I consider this topic not ready for
any
> WG action.
> 
> Concerning missing hardware: The approach of the interfaces model is to
> support provisioning of interface configuration for non-existing
interfaces.
> Hence, if a server can configure say ATM line cards, then the server
should
> announce support for the ATM specific YANG modules independently of the
> question whether ATM line cards are currently present. To find out which
> hardware is present at a specific point in time, consult the ietf-hardware
> model. I do not see why a change to yang library would be needed to deal
> with missing hardware nor do I recall what the proposed edits were.
> 
> design never went into the details of modular servers like SNMP did with
> standards for subagent technologies etc. In the YANG world, this is all
> entirely implementation specific and frankly I would not open this can of
> worms. If the presence of some hardware enables server functionality (or a
> license that is installed), then this may lead to an update of the content
of
> the yang library, like a restart of a NC/RC server may do. I do not see
which
> technical change would be needed.
> 
> The bottom line is that without concrete actionable proposals, we should
not
> delay the finishing of NMDA work. And as Andy says, things that can be
done
> with augmentations are good to do with augmentations.
> 
> /js
> 
> > I do not think the minutes are going to tell you anymore about the
> requirement. So let me take a stab at what I think the requirement is.
> >
> > YANG Library currently compiles a list of modules (and sub-modules) that
> are supported by the device. The same device might also support the
> concept of licensing, where the license controls whether the feature can
be
> enabled on the device, e.g. BGP. The server has the ability to support BGP
as
> a feature (the software exists), but the customer has not bought a license
for
> the BGP feature. What should the server do under the circumstances?
> Should it advertise BGP module, and have the request from the client fail?
Or
> should there another flag, either in the YANG Library or some other module
> that informs the client that although the device is capable of supporting
BGP,
> it cannot because it lacks the license.
> >
> > A similar scenario exists with YANG modules that support a particular
line
> card, and that line card is hot pluggable. What should the YANG library do
for
> modules that it advertises, but the line card for that module may or may
not
> exist in the system?
> > The requirement here is whether semantic versioning can be supported in
> the YANG library in addition to the current version, which is a date.
Details on
> how it relates to YANG Library should be brought up on the list,
preferably on
> a new thread.
> >
> > >
> > > Which, btw, I also am not sure about how and where that came up and
> what it means. In consequence - as Jürgen - I am curious to see the
minutes.
> >
> > Thanks to Robert for updating the rough minutes. If anyone disagrees
with
> what is recorded in the rough notes, please listen to the recording here
> <https://www.ietf.org/audio/ietf100/> and update the rough notes. They
> will be published as official minutes.
> >
> > Mahesh Jethanandani
> > [email-masked]
> >
>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 29 Nov 2017 12:58:27 +0000

The final structure that I presented in the NETCONF session (e.g. a list 
of named schema) should be sufficient to cover licensing (in a future 
piece of work).  Martin has a further tweak to this to allow a datastore 
to indicate which version of the schema is uses, effectively solving the 
issue of wanting a different small schema just for an I2RS datastore.  I 
think that we should update the library draft to this latest version so 
that the WG can review and discuss it.

I don't know if the proposed structure will be sufficient to support 
semantic versioning (beyond just adding a semantic version leaf).  
Fundamentally I think that this will depend on whether a single schema 
can implement two different revisions of a model.  I think that this 
question needs a lot more thought and discussion, and my instinct is 
that the answer to this question may well be that this will not be 
allowed, and hence the existing proposed structure will be sufficient.  
Of course, it is hard to accurately predict the future.

But I do completely agree with Juergen in that I don't think that we 
should be delaying finishing the current version of YANG library bis to 
investigate semantic versioning or licensing. Working out the nuances 
associated with these issues may take a year or more.

I think that we need to finish the NMDA work that we have started (and 
are close to finishing), ensuring that the YANG library structure that 
we choose isn't obviously wrong for what we want to do in the future (it 
doesn't appear to be), but not make the structure more complex than it 
needs to be just to support a potential future requirement that may or 
may not turn out to be valid.

Just my thoughts,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Wed, 29 Nov 2017 15:30:29 +0000

> that the WG can review and discuss it.

Or just posted to the listed, even if not in a draft.  It seems that a
radical restructuring from -02 is being considered now, it might be good
to get by-in before posting a draft update.   Either way is fine; we can
always revert if needed.

> Of course, it is hard to accurately predict the future.

The current -02 structure supports sem-ver, however it might evolve, 
in that the primary key to its lists is an innocuous "id" leaf.  The
current/proposed -03 version uses "name + revision" as the key, which
introduces the possibility of an issue when we try to do sem-ver later,
and by "later", I assume that we agree that it is a pressing issue that
should be addressed shortly.  

> associated with these issues may take a year or more.

I'm assume that licenses are best supported by features.  Even if the
features are not in the base module, a vendor can augment the base 
module with features, which should work I think.

As for sem-ver, I agree that this feature requests seems like its 
sneaking in at the last hour, but I'd rather have a yang library 
that has no possible conflict, which is assured when the key field
doesn't reference module names and revisions.

> may not turn out to be valid.

I don't want to solve sem-ver now.  My only hope this version doesn't
back us into a corner.  Thoughts?

Kent  // contributor

Just my thoughts,
Rob

On 29/11/2017 08:57, Juergen Schoenwaelder wrote:
>> Thanks to Robert for updating the rough minutes. If anyone disagrees with what is recorded in the rough notes, please listen to the recording here <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_audio_ietf100_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fdDxB06_BmpStAKVJsji-JktzcZ-x38ur5ZYjTdcyQg&s=dvERz0NmffzDbS5nIz31U_3mJ_pHdNFOlyBOTMLNu5w&e=> and update the rough notes. They will be published as official minutes.
>>
>> Mahesh Jethanandani
>> [email-masked]
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fdDxB06_BmpStAKVJsji-JktzcZ-x38ur5ZYjTdcyQg&s=SmYOad736PBCN3VI5YxMF0BHB7JfIy-qIk7kSU4OPss&e=
>

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fdDxB06_BmpStAKVJsji-JktzcZ-x38ur5ZYjTdcyQg&s=SmYOad736PBCN3VI5YxMF0BHB7JfIy-qIk7kSU4OPss&e=

---

From: Rohit R Ranade <[email-masked]>
Date: Thu, 30 Nov 2017 05:27:38 +0000

Hi Mahesh,

Whether we can consider this problem similar to windows-APP installation vs usage.  In windows installed-application list, we may see the application being installed but once we try to open the application, we may get an error that the license has expired.

I prefer the yang-library to show the list of application which are installed.

With Regards,
Rohit R

From: Netconf [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: 29 November 2017 00:33
To: Henk Birkholz <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting

On Nov 28, 2017, at 5:17 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Thanks to Robert for updating the rough minutes. If anyone disagrees with what is recorded in the rough notes, please listen to the recording here<https://www.ietf.org/audio/ietf100/> and update the rough notes. They will be published as official minutes.

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>