Re: [netmod] [Netconf] LC on YANG Library (bis)

[Mahesh Jethanandani]

This officially closes the LC on YANG Library bis draft. I know that separately 
there has been a YANG Doctors review of this draft.

Authors, please post an updated draft addressing the comments received during 
LC and other reviews on the document. I will then do a shepherd’s writeup and 
send it for publication.

Thanks.

Mahesh //as shepherd

> On Feb 16, 2018, at 8:04 AM, Robert Wilton  wrote:
> 
> 
> 
> On 16/02/2018 15:33, Ladislav Lhotka wrote:
>> Robert Wilton  writes:
>> 
>>> Hi Lada,
>>> 
>>> 
>>> On 16/02/2018 09:06, Ladislav Lhotka wrote:
 Robert Wilton  writes:
 
> I should add, as a contributor, I have read this document and think that
> is ready for advancement.
> 
> I have three minor comments:
> 
> 1) module "feature" in YANG library is a leaf-list, but currently it is
> a list in YANG libary bis. I suspect that this is due to one of the
> incarnations when it contained additional information.  I think that we
> should revert it back to being a leaf list for consistency.
> 
> 2) Lada recommended that module "deviation" be made a leaf-list. I also
> support changing this for consistency with "feature" above, but don't
> feel too strongly on this one.
 I agree to have both as leaf-lists.
 
> 3) I think the "modules" list is also allowed to included modules that
> don't actually contain any nodes that require implementation.  Hence, it
> might be useful of the "modules" description statement explicitly stated
> this.  I.e. perhaps something like:
> 
> "This list may contain modules that do not contain any schema nodes that
> require implementation.  For example, it could contain a module that
> only defines types and not any data nodes, RPCs, actions, notifications,
> or deviations."
 Hmm, such modules belong to the other list "import-only-modules", don't
 they?
>>> So my reasoning is that either is valid.
>>> 
>>> I.e. a module being listed under "modules" means that it implements all
>>> data nodes, RPCs, actions, notifications, deviations, etc.  If a module
>>> doesn't contain any data nodes, RPCs, actions, notifications,
>>> deviations, etc then it is trivially implemented :-)
>> OK, so if a module contains only groupings and typedefs, it can appear
>> either in "modules" or in "import-only-modules", and the effect is the
>> same, right?
> Yes.
> 
>> 
>> This sounds reasonable.
>> 
>>> As an aside, RFC 7950 states in 5.6.5:
>>> 
>>>   A server implements a module if it implements the module's data
>>> nodes, RPCs, actions, notifications, and deviations.
>>> 
>>> 
>>> I wonder whether identities shouldn't also be on this list, since
>>> section 9.10.2 states:
>> Yes, and extensions as well.
>> 
>> Lada
> Thanks,
> Rob
> 
>> 
>>> On a particular server, the valid values are further restricted
>>> to the set of identities defined in the modules implemented by the server.
>>> 
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
 Lada
 
> Thanks,
> Rob
> 
> 
> On 02/02/2018 13:51, Kent Watsen wrote:
>> As co-author, I am not aware of any IPR related to this document.
>> 
>> As a contributor, I have read this document and think that it is ready
>> for advancement.
>> 
>> Kent
>> 
>> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
>>  on behalf
>> of rwil...@cisco.com > wrote:
>> 
>> I am not aware of any IPR related to this document.
>> 
>> Thanks,
>> Rob
>> 
>> On 01/02/2018 18:59, Mahesh Jethanandani wrote:
>> 
>>  WG,
>> 
>>  The authors of rfc7895bis have indicated that they believe the
>>  document is ready for LC[1].
>> 
>>  This starts a two week LC on the draft
>>  
>> .
>>  The LC will end on February 15.
>> 
>>  Please send your comments on this thread. Reviews of the document,
>>  and statement of support are particularly helpful to the authors.
>>  If you have concerns about the document, please state those too.
>> 
>>  Authors please indicate if you are aware of any IPR on the document.
>> 
>>  Thanks.
>> 
>>  [1]
>>  https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>>  
>> 

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Robert Wilton]

On 16/02/2018 15:33, Ladislav Lhotka wrote:

Robert Wilton  writes:


Hi Lada,


On 16/02/2018 09:06, Ladislav Lhotka wrote:

Robert Wilton  writes:


I should add, as a contributor, I have read this document and think that
is ready for advancement.

I have three minor comments:

1) module "feature" in YANG library is a leaf-list, but currently it is
a list in YANG libary bis. I suspect that this is due to one of the
incarnations when it contained additional information.  I think that we
should revert it back to being a leaf list for consistency.

2) Lada recommended that module "deviation" be made a leaf-list. I also
support changing this for consistency with "feature" above, but don't
feel too strongly on this one.

I agree to have both as leaf-lists.


3) I think the "modules" list is also allowed to included modules that
don't actually contain any nodes that require implementation.  Hence, it
might be useful of the "modules" description statement explicitly stated
this.  I.e. perhaps something like:

"This list may contain modules that do not contain any schema nodes that
require implementation.  For example, it could contain a module that
only defines types and not any data nodes, RPCs, actions, notifications,
or deviations."

Hmm, such modules belong to the other list "import-only-modules", don't
they?

So my reasoning is that either is valid.

I.e. a module being listed under "modules" means that it implements all
data nodes, RPCs, actions, notifications, deviations, etc.  If a module
doesn't contain any data nodes, RPCs, actions, notifications,
deviations, etc then it is trivially implemented :-)

OK, so if a module contains only groupings and typedefs, it can appear
either in "modules" or in "import-only-modules", and the effect is the
same, right?

Yes.



This sounds reasonable.


As an aside, RFC 7950 states in 5.6.5:

   A server implements a module if it implements the module's data
 nodes, RPCs, actions, notifications, and deviations.


I wonder whether identities shouldn't also be on this list, since
section 9.10.2 states:

Yes, and extensions as well.

Lada

Thanks,
Rob




On a particular server, the valid values are further restricted
to the set of identities defined in the modules implemented by the server.


Thanks,
Rob



Lada


Thanks,
Rob


On 02/02/2018 13:51, Kent Watsen wrote:

As co-author, I am not aware of any IPR related to this document.

As a contributor, I have read this document and think that it is ready
for advancement.

Kent

On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
 on behalf
of rwil...@cisco.com > wrote:

I am not aware of any IPR related to this document.

Thanks,
Rob

On 01/02/2018 18:59, Mahesh Jethanandani wrote:

  WG,

  The authors of rfc7895bis have indicated that they believe the
  document is ready for LC[1].

  This starts a two week LC on the draft
  
.
  The LC will end on February 15.

  Please send your comments on this thread. Reviews of the document,
  and statement of support are particularly helpful to the authors.
  If you have concerns about the document, please state those too.

  Authors please indicate if you are aware of any IPR on the document.

  Thanks.

  [1]
  https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
  


  Mahesh & Kent




  ___

  Netconf mailing list

  netc...@ietf.org 

  https://www.ietf.org/mailman/listinfo/netconf
  





___
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

___
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Ladislav Lhotka]

Robert Wilton  writes:

> Hi Lada,
>
>
> On 16/02/2018 09:06, Ladislav Lhotka wrote:
>> Robert Wilton  writes:
>>
>>> I should add, as a contributor, I have read this document and think that
>>> is ready for advancement.
>>>
>>> I have three minor comments:
>>>
>>> 1) module "feature" in YANG library is a leaf-list, but currently it is
>>> a list in YANG libary bis. I suspect that this is due to one of the
>>> incarnations when it contained additional information.  I think that we
>>> should revert it back to being a leaf list for consistency.
>>>
>>> 2) Lada recommended that module "deviation" be made a leaf-list. I also
>>> support changing this for consistency with "feature" above, but don't
>>> feel too strongly on this one.
>> I agree to have both as leaf-lists.
>>
>>> 3) I think the "modules" list is also allowed to included modules that
>>> don't actually contain any nodes that require implementation.  Hence, it
>>> might be useful of the "modules" description statement explicitly stated
>>> this.  I.e. perhaps something like:
>>>
>>> "This list may contain modules that do not contain any schema nodes that
>>> require implementation.  For example, it could contain a module that
>>> only defines types and not any data nodes, RPCs, actions, notifications,
>>> or deviations."
>> Hmm, such modules belong to the other list "import-only-modules", don't
>> they?
> So my reasoning is that either is valid.
>
> I.e. a module being listed under "modules" means that it implements all 
> data nodes, RPCs, actions, notifications, deviations, etc.  If a module 
> doesn't contain any data nodes, RPCs, actions, notifications, 
> deviations, etc then it is trivially implemented :-)

OK, so if a module contains only groupings and typedefs, it can appear
either in "modules" or in "import-only-modules", and the effect is the
same, right?

This sounds reasonable.

>
> As an aside, RFC 7950 states in 5.6.5:
>
>   A server implements a module if it implements the module's data
> nodes, RPCs, actions, notifications, and deviations.
>
>
> I wonder whether identities shouldn't also be on this list, since 
> section 9.10.2 states:

Yes, and extensions as well.

Lada

>
> On a particular server, the valid values are further restricted
> to the set of identities defined in the modules implemented by the server.
>
>
> Thanks,
> Rob
>
>
>>
>> Lada
>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 02/02/2018 13:51, Kent Watsen wrote:
 As co-author, I am not aware of any IPR related to this document.

 As a contributor, I have read this document and think that it is ready
 for advancement.

 Kent

 On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
  on behalf
 of rwil...@cisco.com > wrote:

 I am not aware of any IPR related to this document.

 Thanks,
 Rob

 On 01/02/2018 18:59, Mahesh Jethanandani wrote:

  WG,

  The authors of rfc7895bis have indicated that they believe the
  document is ready for LC[1].

  This starts a two week LC on the draft
  
 .
  The LC will end on February 15.

  Please send your comments on this thread. Reviews of the document,
  and statement of support are particularly helpful to the authors.
  If you have concerns about the document, please state those too.

  Authors please indicate if you are aware of any IPR on the document.

  Thanks.

  [1]
  https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
  
 

  Mahesh & Kent




  ___

  Netconf mailing list

  netc...@ietf.org 

  https://www.ietf.org/mailman/listinfo/netconf
  
 



>>> ___
>>> Netconf mailing list
>>> netc...@ietf.org
>>> 

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Robert Wilton]

Hi Lada,


On 16/02/2018 09:06, Ladislav Lhotka wrote:

Robert Wilton  writes:


I should add, as a contributor, I have read this document and think that
is ready for advancement.

I have three minor comments:

1) module "feature" in YANG library is a leaf-list, but currently it is
a list in YANG libary bis. I suspect that this is due to one of the
incarnations when it contained additional information.  I think that we
should revert it back to being a leaf list for consistency.

2) Lada recommended that module "deviation" be made a leaf-list. I also
support changing this for consistency with "feature" above, but don't
feel too strongly on this one.

I agree to have both as leaf-lists.


3) I think the "modules" list is also allowed to included modules that
don't actually contain any nodes that require implementation.  Hence, it
might be useful of the "modules" description statement explicitly stated
this.  I.e. perhaps something like:

"This list may contain modules that do not contain any schema nodes that
require implementation.  For example, it could contain a module that
only defines types and not any data nodes, RPCs, actions, notifications,
or deviations."

Hmm, such modules belong to the other list "import-only-modules", don't
they?

So my reasoning is that either is valid.

I.e. a module being listed under "modules" means that it implements all 
data nodes, RPCs, actions, notifications, deviations, etc.  If a module 
doesn't contain any data nodes, RPCs, actions, notifications, 
deviations, etc then it is trivially implemented :-)


As an aside, RFC 7950 states in 5.6.5:

 A server implements a module if it implements the module's data
   nodes, RPCs, actions, notifications, and deviations.


I wonder whether identities shouldn't also be on this list, since 
section 9.10.2 states:


On a particular server, the valid values are further restricted
to the set of identities defined in the modules implemented by the server.


Thanks,
Rob




Lada


Thanks,
Rob


On 02/02/2018 13:51, Kent Watsen wrote:

As co-author, I am not aware of any IPR related to this document.

As a contributor, I have read this document and think that it is ready
for advancement.

Kent

On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
 on behalf
of rwil...@cisco.com > wrote:

I am not aware of any IPR related to this document.

Thanks,
Rob

On 01/02/2018 18:59, Mahesh Jethanandani wrote:

 WG,

 The authors of rfc7895bis have indicated that they believe the
 document is ready for LC[1].

 This starts a two week LC on the draft
 
.
 The LC will end on February 15.

 Please send your comments on this thread. Reviews of the document,
 and statement of support are particularly helpful to the authors.
 If you have concerns about the document, please state those too.

 Authors please indicate if you are aware of any IPR on the document.

 Thanks.

 [1]
 https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
 


 Mahesh & Kent




 ___

 Netconf mailing list

 netc...@ietf.org 

 https://www.ietf.org/mailman/listinfo/netconf
 





___
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Ladislav Lhotka]

Andy Bierman  writes:

> On Thu, Feb 15, 2018 at 10:09 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
>> On Thu, Feb 15, 2018 at 05:03:32PM +, Robert Wilton wrote:
>> >
>> > 1) module "feature" in YANG library is a leaf-list, but currently it is a
>> > list in YANG libary bis. I suspect that this is due to one of the
>> > incarnations when it contained additional information.  I think that we
>> > should revert it back to being a leaf list for consistency.
>> >
>> > 2) Lada recommended that module "deviation" be made a leaf-list. I also
>> > support changing this for consistency with "feature" above, but don't
>> feel
>> > too strongly on this one.
>> >
>>
>> I suggest we either make both leaf-lists or keep both as lists. I am
>> fine with making both lead-lists.
>>
>>
>
> The reason the deviation is a list is because it has a name and revision.
> Or it did until it was removed.
>
> I prefer to keep the contents of the "module" list the
> same as RFC 7895.  The "improvement" is much worse --
> harder to use by clients and provides less information to clients.

So we currently have:

1. "deviation": [
 {
   "module": "foo-devs"
 },
 {
   "module": "bar-devs"
 }
   ]

and the proposal is to have instead

2. "deviation-module": [
 "foo-devs",
 "bar-dev"
   ]

I fail to see why #2 is harder to use for clients, I would say it is the
opposite. Also, #2 doesn't provide less information than RFC 7895 - the
revision parameter is readily available in the "module" list.

I also expect that this data will be used not only in machine-to-machine
communication but could also be perused by humans - see
e.g. draft-lengyel-netmod-yang-instance-data. For this purpose, #2 is a
clear winer.

Lada

>
>
>
>> /js
>>
>
>
> Andy
>
>
>>
>> --
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
>>
>> ___
>> Netconf mailing list
>> netc...@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Ladislav Lhotka]

Robert Wilton  writes:

> I should add, as a contributor, I have read this document and think that 
> is ready for advancement.
>
> I have three minor comments:
>
> 1) module "feature" in YANG library is a leaf-list, but currently it is 
> a list in YANG libary bis. I suspect that this is due to one of the 
> incarnations when it contained additional information.  I think that we 
> should revert it back to being a leaf list for consistency.
>
> 2) Lada recommended that module "deviation" be made a leaf-list. I also 
> support changing this for consistency with "feature" above, but don't 
> feel too strongly on this one.

I agree to have both as leaf-lists.

>
> 3) I think the "modules" list is also allowed to included modules that 
> don't actually contain any nodes that require implementation.  Hence, it 
> might be useful of the "modules" description statement explicitly stated 
> this.  I.e. perhaps something like:
>
> "This list may contain modules that do not contain any schema nodes that 
> require implementation.  For example, it could contain a module that 
> only defines types and not any data nodes, RPCs, actions, notifications, 
> or deviations."

Hmm, such modules belong to the other list "import-only-modules", don't
they?

Lada

>
> Thanks,
> Rob
>
>
> On 02/02/2018 13:51, Kent Watsen wrote:
>>
>> As co-author, I am not aware of any IPR related to this document.
>>
>> As a contributor, I have read this document and think that it is ready 
>> for advancement.
>>
>> Kent
>>
>> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton" 
>>  on behalf 
>> of rwil...@cisco.com > wrote:
>>
>> I am not aware of any IPR related to this document.
>>
>> Thanks,
>> Rob
>>
>> On 01/02/2018 18:59, Mahesh Jethanandani wrote:
>>
>> WG,
>>
>> The authors of rfc7895bis have indicated that they believe the
>> document is ready for LC[1].
>>
>> This starts a two week LC on the draft
>> 
>> .
>> The LC will end on February 15.
>>
>> Please send your comments on this thread. Reviews of the document,
>> and statement of support are particularly helpful to the authors.
>> If you have concerns about the document, please state those too.
>>
>> Authors please indicate if you are aware of any IPR on the document.
>>
>> Thanks.
>>
>> [1]
>> https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>> 
>> 
>>
>> Mahesh & Kent
>>
>>
>>
>>
>> ___
>>
>> Netconf mailing list
>>
>> netc...@ietf.org 
>>
>> https://www.ietf.org/mailman/listinfo/netconf
>> 
>> 
>>
>>
>>
>
> ___
> Netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Alexander Clemm]

Hi Kent,

yes, it wouldn't have to be in this document.  But I do think a solution for 
this is clearly needed, and YANG library (or augmentation to it) is the best 
way to put it.  

I wasn't planning to put out an I-D on this myself, but can put it on my to-do 
list (and will be happy to contribute if someone wants to take the lead).  

--- Alex

> -Original Message-
> From: Kent Watsen [mailto:kwat...@juniper.net]
> Sent: Thursday, February 15, 2018 7:51 AM
> To: Alexander Clemm <alexander.cl...@huawei.com>; Juergen
> Schoenwaelder <j.schoenwael...@jacobs-university.de>
> Cc: NETCONF WG <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
> Subject: Re: [Netconf] [netmod] LC on YANG Library (bis)
> 
> Alex,
> 
> What you want makes sense to me.  How about putting it into an I-D that
> augments the yang library bis?  It doesn't have to be in this document, right?
> 
> Kent
> 
> = original message =
> 
> Well, we need a general solution for that.  YANG-push is just one use case.  
> There
> are other cases where there will be "metadata" (that does not pertain to 
> instance
> data)  and capabilities that clients want to discover.  YANG library (in 
> itself
> providing "metadata" about what a server supports and is capable of) is an
> excellent place to maintain this information.  It also provides the 
> opportunity to
> be systemic about it, as opposed to requiring everyone to define their own 
> little
> custom extensions.
> --- Alex
> 
> > -Original Message-
> > From: Juergen Schoenwaelder
> > [mailto:j.schoenwael...@jacobs-university.de]
> > Sent: Tuesday, February 13, 2018 11:48 AM
> > To: Alexander Clemm <alexander.cl...@huawei.com>
> > Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
> > <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
> > Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> >
> > Alexander,
> >
> > I disagree. This YANG Library is mandatory for all implementations;
> > what you talk about seems to concern only implementations that support
> > YANG push. Hence, this is an extension that should go in its own module.
> >
> > /js
> >
> > On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:
> > > Hi,
> > >
> > > I have taken a look at this document.
> > >
> > > My main comment is that one aspect that is missing, that I believe
> > > should be
> > added, concerns the inclusion of certain metadata about the modules.
> > Specifically, in the context of YANG-Push we had a discussion about
> > being able to mark nodes that are notifiable on change.  This is just
> > one particular use case of a more general issue; in YANG-Push after
> > much debate the conclusion was for now to simply make implementors
> > aware of this issue and advise that a solution to this must be
> > provided, with the clear understanding that eventually a standard solution
> should be defined.
> > >
> > > Since the goal of YANG-Library is to allow clients to find out what
> > > is actually
> > supported on a given server, this is the right place to keep this
> > information.  One possible way to address this would be, for a given
> > module, to maintain a list of "meta-info", with a key "meta-tag", and
> > a list with references to the nodes to which the metadata applies.  In
> > the case of notifiable-on-change, you would have a list with one entry
> > "notifiable-on-change", and then the list with the node definitions to 
> > which this
> tag applies.
> > >
> > > Editorial nit:
> > > 2nd paragraph Introduction: informaton --> information
> > >
> > > Thanks
> > > --- Alex
> > >
> > > From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Mahesh
> > > Jethanandani
> > > Sent: Thursday, February 01, 2018 11:00 AM
> > > To: NETCONF WG <netc...@ietf.org>
> > > Cc: NETMOD WG <netmod@ietf.org>
> > > Subject: [Netconf] LC on YANG Library (bis)
> > >
> > > WG,
> > >
> > > The authors of rfc7895bis have indicated that they believe the
> > > document is
> > ready for LC[1].
> > >
> > > This starts a two week LC on the
> > > draft<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.iet
> > > f.org_html_draft-2Dietf-
> 2D=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-nd
> > >
> b3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=oAL
> b7L
> > >
> KrUkKDsJ06VIM3An

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Andy Bierman]

On Thu, Feb 15, 2018 at 12:12 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Feb 15, 2018 at 11:03:02AM -0800, Andy Bierman wrote:
> >
> > The reason the deviation is a list is because it has a name and revision.
> > Or it did until it was removed.
> >
>
> > I prefer to keep the contents of the "module" list the
> > same as RFC 7895.  The "improvement" is much worse --
> > harder to use by clients and provides less information to clients.
>
> Which "improvement" do you mean? Which information is lost? In which
> situations are things harder to use?
>

The supposed improvement is the /yang-library subtree.

It is now much harder to determine the modules used by the server
because there are 3 data structures to retrieve and process instead of 1.

The module list used to have a deviation list so revisions could be
identified

list deviation {
   key "name revision";
   description
 "List of YANG deviation module names and revisions
  used by this server to modify the conformance of
  the module associated with this entry.  Note that
  the same module can be used for deviations for
  multiple modules, so the same entry MAY appear
  within multiple 'module' entries.

  The deviation module MUST be present in the 'module'
  list, with the same name and revision values.
  The 'conformance-type' value will be 'implement' for
  the deviation module.";
   uses common-leafs;

 }


> /js
>


Andy


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Juergen Schoenwaelder]

On Thu, Feb 15, 2018 at 11:03:02AM -0800, Andy Bierman wrote:
> 
> The reason the deviation is a list is because it has a name and revision.
> Or it did until it was removed.
>

> I prefer to keep the contents of the "module" list the
> same as RFC 7895.  The "improvement" is much worse --
> harder to use by clients and provides less information to clients.

Which "improvement" do you mean? Which information is lost? In which
situations are things harder to use?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Andy Bierman]

On Thu, Feb 15, 2018 at 10:09 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Feb 15, 2018 at 05:03:32PM +, Robert Wilton wrote:
> >
> > 1) module "feature" in YANG library is a leaf-list, but currently it is a
> > list in YANG libary bis. I suspect that this is due to one of the
> > incarnations when it contained additional information.  I think that we
> > should revert it back to being a leaf list for consistency.
> >
> > 2) Lada recommended that module "deviation" be made a leaf-list. I also
> > support changing this for consistency with "feature" above, but don't
> feel
> > too strongly on this one.
> >
>
> I suggest we either make both leaf-lists or keep both as lists. I am
> fine with making both lead-lists.
>
>

The reason the deviation is a list is because it has a name and revision.
Or it did until it was removed.

I prefer to keep the contents of the "module" list the
same as RFC 7895.  The "improvement" is much worse --
harder to use by clients and provides less information to clients.



> /js
>


Andy


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> Netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Juergen Schoenwaelder]

On Thu, Feb 15, 2018 at 05:03:32PM +, Robert Wilton wrote:
> 
> 1) module "feature" in YANG library is a leaf-list, but currently it is a
> list in YANG libary bis. I suspect that this is due to one of the
> incarnations when it contained additional information.  I think that we
> should revert it back to being a leaf list for consistency.
> 
> 2) Lada recommended that module "deviation" be made a leaf-list. I also
> support changing this for consistency with "feature" above, but don't feel
> too strongly on this one.
>

I suggest we either make both leaf-lists or keep both as lists. I am
fine with making both lead-lists.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Robert Wilton]

I should add, as a contributor, I have read this document and think that 
is ready for advancement.


I have three minor comments:

1) module "feature" in YANG library is a leaf-list, but currently it is 
a list in YANG libary bis. I suspect that this is due to one of the 
incarnations when it contained additional information.  I think that we 
should revert it back to being a leaf list for consistency.


2) Lada recommended that module "deviation" be made a leaf-list. I also 
support changing this for consistency with "feature" above, but don't 
feel too strongly on this one.


3) I think the "modules" list is also allowed to included modules that 
don't actually contain any nodes that require implementation.  Hence, it 
might be useful of the "modules" description statement explicitly stated 
this.  I.e. perhaps something like:


"This list may contain modules that do not contain any schema nodes that 
require implementation.  For example, it could contain a module that 
only defines types and not any data nodes, RPCs, actions, notifications, 
or deviations."


Thanks,
Rob


On 02/02/2018 13:51, Kent Watsen wrote:


As co-author, I am not aware of any IPR related to this document.

As a contributor, I have read this document and think that it is ready 
for advancement.


Kent

On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton" 
 on behalf 
of rwil...@cisco.com > wrote:


I am not aware of any IPR related to this document.

Thanks,
Rob

On 01/02/2018 18:59, Mahesh Jethanandani wrote:

WG,

The authors of rfc7895bis have indicated that they believe the
document is ready for LC[1].

This starts a two week LC on the draft

.
The LC will end on February 15.

Please send your comments on this thread. Reviews of the document,
and statement of support are particularly helpful to the authors.
If you have concerns about the document, please state those too.

Authors please indicate if you are aware of any IPR on the document.

Thanks.

[1]
https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html



Mahesh & Kent




___

Netconf mailing list

netc...@ietf.org 

https://www.ietf.org/mailman/listinfo/netconf







___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Kent Watsen]

Alex,

What you want makes sense to me.  How about putting it into an I-D that 
augments the yang library bis?  It doesn't have to be in this document, right?

Kent

= original message =

Well, we need a general solution for that.  YANG-push is just one use case.  
There are other cases where there will be "metadata" (that does not pertain to 
instance data)  and capabilities that clients want to discover.  YANG library 
(in itself providing "metadata" about what a server supports and is capable of) 
is an excellent place to maintain this information.  It also provides the 
opportunity to be systemic about it, as opposed to requiring everyone to define 
their own little custom extensions.  
--- Alex

> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Tuesday, February 13, 2018 11:48 AM
> To: Alexander Clemm <alexander.cl...@huawei.com>
> Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
> <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> 
> Alexander,
> 
> I disagree. This YANG Library is mandatory for all implementations; what you 
> talk
> about seems to concern only implementations that support YANG push. Hence,
> this is an extension that should go in its own module.
> 
> /js
> 
> On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:
> > Hi,
> >
> > I have taken a look at this document.
> >
> > My main comment is that one aspect that is missing, that I believe should be
> added, concerns the inclusion of certain metadata about the modules.
> Specifically, in the context of YANG-Push we had a discussion about being 
> able to
> mark nodes that are notifiable on change.  This is just one particular use 
> case of a
> more general issue; in YANG-Push after much debate the conclusion was for now
> to simply make implementors aware of this issue and advise that a solution to
> this must be provided, with the clear understanding that eventually a standard
> solution should be defined.
> >
> > Since the goal of YANG-Library is to allow clients to find out what is 
> > actually
> supported on a given server, this is the right place to keep this 
> information.  One
> possible way to address this would be, for a given module, to maintain a list 
> of
> "meta-info", with a key "meta-tag", and a list with references to the nodes to
> which the metadata applies.  In the case of notifiable-on-change, you would 
> have
> a list with one entry "notifiable-on-change", and then the list with the node
> definitions to which this tag applies.
> >
> > Editorial nit:
> > 2nd paragraph Introduction: informaton --> information
> >
> > Thanks
> > --- Alex
> >
> > From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Mahesh
> > Jethanandani
> > Sent: Thursday, February 01, 2018 11:00 AM
> > To: NETCONF WG <netc...@ietf.org>
> > Cc: NETMOD WG <netmod@ietf.org>
> > Subject: [Netconf] LC on YANG Library (bis)
> >
> > WG,
> >
> > The authors of rfc7895bis have indicated that they believe the document is
> ready for LC[1].
> >
> > This starts a two week LC on the 
> > draft<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=oALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA=NaY8R9DBhInZQAxL35_KjFzeYHfyTOVJLnMHAKGeKF0=
> netconf-rfc7895bis-04>. The LC will end on February 15.
> >
> > Please send your comments on this thread. Reviews of the document, and
> statement of support are particularly helpful to the authors. If you have 
> concerns
> about the document, please state those too.
> >
> > Authors please indicate if you are aware of any IPR on the document.
> >
> > Thanks.
> >
> > [1]
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_netconf_current_msg13980.html=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=oALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA=Qm6U9CIpDHS0jqUnGGZl8X05qeA_VvMyyuOtwDHBf1M=
> >
> > Mahesh & Kent
> >
> 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=oALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA=GPdqli

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Ladislav Lhotka]

Robert Wilton <rwil...@cisco.com> writes:

> Hi Alex,
>
> I see no real advantages to putting this directly in YANG library bis, 
> but I think that augmenting the YANG library bis structure is just fine 
> (in the same way that the latest version of schema mount has proposed to 
> do).
>
> Generally, I think that it is good that NETCONF/YANG is built up of 
> fairly loosely coupled components.  E.g. implementations can choose 
> which subset of features are required for their particular circumstances 
> (e.g. protocol, encoding, schema mount, YANG push, with-defaults, etc).  
> If over time it becomes clear that it is critical for good interop that 
> particular features must always be supported then we can define NETCONF 
> 2.0 or 3.0 that mandates that a particular set of technologies must be 
> implemented to meet the standard.
>
> The added bonus of having these components loosely coupled is that they 
> can be improved and refined independently, potentially allowing IETF to 
> move a bit quicker advancing the technologies.
>
> Finally, even if there is common meta-data structure that is shared by 
> multiple features, that still doesn't mean that it has to go in the base 
> YANG library spec, that can still just be shared common extension.

+1

Lada

>
> Thanks,
> Rob
>
>
> On 13/02/2018 21:25, Alexander Clemm wrote:
>> My proposal is to add this to the YANG data model.  I think this logically 
>> belongs to YANG library which is why I would like to see it there.  I also 
>> think it will be useful to many implementations.  All, probably not, but 
>> they have also survived without YANG library for a while:-) Of course, it is 
>> always possible to write another draft or do a bisbis.
>> Cheers
>> --- Alex
>>
>>> -Original Message-
>>> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
>>> Sent: Tuesday, February 13, 2018 12:29 PM
>>> To: Alexander Clemm <alexander.cl...@huawei.com>
>>> Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
>>> <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
>>> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
>>>
>>> I must have missed your actionable proposal that is relevant for _all_ 
>>> NETCONF
>>> and RESTCONF implementations.
>>>
>>> YANG data models are extensible so lets use that.
>>>
>>> /js
>>>
>>> On Tue, Feb 13, 2018 at 07:58:37PM +, Alexander Clemm wrote:
>>>> Well, we need a general solution for that.  YANG-push is just one use case.
>>> There are other cases where there will be "metadata" (that does not pertain 
>>> to
>>> instance data)  and capabilities that clients want to discover.  YANG 
>>> library (in
>>> itself providing "metadata" about what a server supports and is capable of) 
>>> is an
>>> excellent place to maintain this information.  It also provides the 
>>> opportunity to
>>> be systemic about it, as opposed to requiring everyone to define their own 
>>> little
>>> custom extensions.
>>>> --- Alex
>>>>
>>>>> -Original Message-
>>>>> From: Juergen Schoenwaelder
>>>>> [mailto:j.schoenwael...@jacobs-university.de]
>>>>> Sent: Tuesday, February 13, 2018 11:48 AM
>>>>> To: Alexander Clemm <alexander.cl...@huawei.com>
>>>>> Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
>>>>> <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
>>>>> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
>>>>>
>>>>> Alexander,
>>>>>
>>>>> I disagree. This YANG Library is mandatory for all implementations;
>>>>> what you talk about seems to concern only implementations that
>>>>> support YANG push. Hence, this is an extension that should go in its own
>>> module.
>>>>> /js
>>>>>
>>>>> On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have taken a look at this document.
>>>>>>
>>>>>> My main comment is that one aspect that is missing, that I believe
>>>>>> should be
>>>>> added, concerns the inclusion of certain metadata about the modules.
>>>>> Specifically, in the context of YANG-Push we had a discussion about
>>>>> being able to mark nodes that are

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Robert Wilton]

Hi Alex,

I see no real advantages to putting this directly in YANG library bis, 
but I think that augmenting the YANG library bis structure is just fine 
(in the same way that the latest version of schema mount has proposed to 
do).


Generally, I think that it is good that NETCONF/YANG is built up of 
fairly loosely coupled components.  E.g. implementations can choose 
which subset of features are required for their particular circumstances 
(e.g. protocol, encoding, schema mount, YANG push, with-defaults, etc).  
If over time it becomes clear that it is critical for good interop that 
particular features must always be supported then we can define NETCONF 
2.0 or 3.0 that mandates that a particular set of technologies must be 
implemented to meet the standard.


The added bonus of having these components loosely coupled is that they 
can be improved and refined independently, potentially allowing IETF to 
move a bit quicker advancing the technologies.


Finally, even if there is common meta-data structure that is shared by 
multiple features, that still doesn't mean that it has to go in the base 
YANG library spec, that can still just be shared common extension.


Thanks,
Rob


On 13/02/2018 21:25, Alexander Clemm wrote:

My proposal is to add this to the YANG data model.  I think this logically 
belongs to YANG library which is why I would like to see it there.  I also 
think it will be useful to many implementations.  All, probably not, but they 
have also survived without YANG library for a while:-) Of course, it is always 
possible to write another draft or do a bisbis.
Cheers
--- Alex


-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: Tuesday, February 13, 2018 12:29 PM
To: Alexander Clemm <alexander.cl...@huawei.com>
Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
<netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)

I must have missed your actionable proposal that is relevant for _all_ NETCONF
and RESTCONF implementations.

YANG data models are extensible so lets use that.

/js

On Tue, Feb 13, 2018 at 07:58:37PM +, Alexander Clemm wrote:

Well, we need a general solution for that.  YANG-push is just one use case.

There are other cases where there will be "metadata" (that does not pertain to
instance data)  and capabilities that clients want to discover.  YANG library 
(in
itself providing "metadata" about what a server supports and is capable of) is 
an
excellent place to maintain this information.  It also provides the opportunity 
to
be systemic about it, as opposed to requiring everyone to define their own 
little
custom extensions.

--- Alex


-Original Message-
From: Juergen Schoenwaelder
[mailto:j.schoenwael...@jacobs-university.de]
Sent: Tuesday, February 13, 2018 11:48 AM
To: Alexander Clemm <alexander.cl...@huawei.com>
Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
<netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)

Alexander,

I disagree. This YANG Library is mandatory for all implementations;
what you talk about seems to concern only implementations that
support YANG push. Hence, this is an extension that should go in its own

module.

/js

On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:

Hi,

I have taken a look at this document.

My main comment is that one aspect that is missing, that I believe
should be

added, concerns the inclusion of certain metadata about the modules.
Specifically, in the context of YANG-Push we had a discussion about
being able to mark nodes that are notifiable on change.  This is
just one particular use case of a more general issue; in YANG-Push
after much debate the conclusion was for now to simply make
implementors aware of this issue and advise that a solution to this
must be provided, with the clear understanding that eventually a standard

solution should be defined.

Since the goal of YANG-Library is to allow clients to find out
what is actually

supported on a given server, this is the right place to keep this
information.  One possible way to address this would be, for a given
module, to maintain a list of "meta-info", with a key "meta-tag",
and a list with references to the nodes to which the metadata
applies.  In the case of notifiable-on-change, you would have a list
with one entry "notifiable-on-change", and then the list with the node

definitions to which this tag applies.

Editorial nit:
2nd paragraph Introduction: informaton --> information

Thanks
--- Alex

From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of
Mahesh Jethanandani
Sent: Thursday, February 01, 2018 11:00 AM
To: NETCONF WG <netc...@ietf.org>
Cc: NETMOD WG <netmod@ietf.org>
Subject: [Netconf] LC on YANG Library (bis)

WG,

The au

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Andy Bierman]

On Tue, Feb 13, 2018 at 1:25 PM, Alexander Clemm <alexander.cl...@huawei.com
> wrote:

> My proposal is to add this to the YANG data model.  I think this logically
> belongs to YANG library which is why I would like to see it there.  I also
> think it will be useful to many implementations.  All, probably not, but
> they have also survived without YANG library for a while:-) Of course, it
> is always possible to write another draft or do a bisbis.
>

Or the IETF can learn about the augment-stmt and create additional objects
without
constantly rewriting the base modules.


Cheers
> --- Alex
>

Andy


>
> > -Original Message-
> > From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de
> ]
> > Sent: Tuesday, February 13, 2018 12:29 PM
> > To: Alexander Clemm <alexander.cl...@huawei.com>
> > Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
> > <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
> > Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> >
> > I must have missed your actionable proposal that is relevant for _all_
> NETCONF
> > and RESTCONF implementations.
> >
> > YANG data models are extensible so lets use that.
> >
> > /js
> >
> > On Tue, Feb 13, 2018 at 07:58:37PM +, Alexander Clemm wrote:
> > > Well, we need a general solution for that.  YANG-push is just one use
> case.
> > There are other cases where there will be "metadata" (that does not
> pertain to
> > instance data)  and capabilities that clients want to discover.  YANG
> library (in
> > itself providing "metadata" about what a server supports and is capable
> of) is an
> > excellent place to maintain this information.  It also provides the
> opportunity to
> > be systemic about it, as opposed to requiring everyone to define their
> own little
> > custom extensions.
> > > --- Alex
> > >
> > > > -Original Message-
> > > > From: Juergen Schoenwaelder
> > > > [mailto:j.schoenwael...@jacobs-university.de]
> > > > Sent: Tuesday, February 13, 2018 11:48 AM
> > > > To: Alexander Clemm <alexander.cl...@huawei.com>
> > > > Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
> > > > <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
> > > > Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> > > >
> > > > Alexander,
> > > >
> > > > I disagree. This YANG Library is mandatory for all implementations;
> > > > what you talk about seems to concern only implementations that
> > > > support YANG push. Hence, this is an extension that should go in its
> own
> > module.
> > > >
> > > > /js
> > > >
> > > > On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:
> > > > > Hi,
> > > > >
> > > > > I have taken a look at this document.
> > > > >
> > > > > My main comment is that one aspect that is missing, that I believe
> > > > > should be
> > > > added, concerns the inclusion of certain metadata about the modules.
> > > > Specifically, in the context of YANG-Push we had a discussion about
> > > > being able to mark nodes that are notifiable on change.  This is
> > > > just one particular use case of a more general issue; in YANG-Push
> > > > after much debate the conclusion was for now to simply make
> > > > implementors aware of this issue and advise that a solution to this
> > > > must be provided, with the clear understanding that eventually a
> standard
> > solution should be defined.
> > > > >
> > > > > Since the goal of YANG-Library is to allow clients to find out
> > > > > what is actually
> > > > supported on a given server, this is the right place to keep this
> > > > information.  One possible way to address this would be, for a given
> > > > module, to maintain a list of "meta-info", with a key "meta-tag",
> > > > and a list with references to the nodes to which the metadata
> > > > applies.  In the case of notifiable-on-change, you would have a list
> > > > with one entry "notifiable-on-change", and then the list with the
> node
> > definitions to which this tag applies.
> > > > >
> > > > > Editorial nit:
> > > > > 2nd paragraph Introduction: informaton --> information
> > > > >

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Alexander Clemm]

My proposal is to add this to the YANG data model.  I think this logically 
belongs to YANG library which is why I would like to see it there.  I also 
think it will be useful to many implementations.  All, probably not, but they 
have also survived without YANG library for a while:-) Of course, it is always 
possible to write another draft or do a bisbis.  
Cheers
--- Alex

> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Tuesday, February 13, 2018 12:29 PM
> To: Alexander Clemm <alexander.cl...@huawei.com>
> Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
> <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> 
> I must have missed your actionable proposal that is relevant for _all_ NETCONF
> and RESTCONF implementations.
> 
> YANG data models are extensible so lets use that.
> 
> /js
> 
> On Tue, Feb 13, 2018 at 07:58:37PM +, Alexander Clemm wrote:
> > Well, we need a general solution for that.  YANG-push is just one use case.
> There are other cases where there will be "metadata" (that does not pertain to
> instance data)  and capabilities that clients want to discover.  YANG library 
> (in
> itself providing "metadata" about what a server supports and is capable of) 
> is an
> excellent place to maintain this information.  It also provides the 
> opportunity to
> be systemic about it, as opposed to requiring everyone to define their own 
> little
> custom extensions.
> > --- Alex
> >
> > > -Original Message-
> > > From: Juergen Schoenwaelder
> > > [mailto:j.schoenwael...@jacobs-university.de]
> > > Sent: Tuesday, February 13, 2018 11:48 AM
> > > To: Alexander Clemm <alexander.cl...@huawei.com>
> > > Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
> > > <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
> > > Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> > >
> > > Alexander,
> > >
> > > I disagree. This YANG Library is mandatory for all implementations;
> > > what you talk about seems to concern only implementations that
> > > support YANG push. Hence, this is an extension that should go in its own
> module.
> > >
> > > /js
> > >
> > > On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:
> > > > Hi,
> > > >
> > > > I have taken a look at this document.
> > > >
> > > > My main comment is that one aspect that is missing, that I believe
> > > > should be
> > > added, concerns the inclusion of certain metadata about the modules.
> > > Specifically, in the context of YANG-Push we had a discussion about
> > > being able to mark nodes that are notifiable on change.  This is
> > > just one particular use case of a more general issue; in YANG-Push
> > > after much debate the conclusion was for now to simply make
> > > implementors aware of this issue and advise that a solution to this
> > > must be provided, with the clear understanding that eventually a standard
> solution should be defined.
> > > >
> > > > Since the goal of YANG-Library is to allow clients to find out
> > > > what is actually
> > > supported on a given server, this is the right place to keep this
> > > information.  One possible way to address this would be, for a given
> > > module, to maintain a list of "meta-info", with a key "meta-tag",
> > > and a list with references to the nodes to which the metadata
> > > applies.  In the case of notifiable-on-change, you would have a list
> > > with one entry "notifiable-on-change", and then the list with the node
> definitions to which this tag applies.
> > > >
> > > > Editorial nit:
> > > > 2nd paragraph Introduction: informaton --> information
> > > >
> > > > Thanks
> > > > --- Alex
> > > >
> > > > From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of
> > > > Mahesh Jethanandani
> > > > Sent: Thursday, February 01, 2018 11:00 AM
> > > > To: NETCONF WG <netc...@ietf.org>
> > > > Cc: NETMOD WG <netmod@ietf.org>
> > > > Subject: [Netconf] LC on YANG Library (bis)
> > > >
> > > > WG,
> > > >
> > > > The authors of rfc7895bis have indicated that they believe the
> > > > document is
> > > read

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Juergen Schoenwaelder]

I must have missed your actionable proposal that is relevant for _all_
NETCONF and RESTCONF implementations.

YANG data models are extensible so lets use that.

/js

On Tue, Feb 13, 2018 at 07:58:37PM +, Alexander Clemm wrote:
> Well, we need a general solution for that.  YANG-push is just one use case.  
> There are other cases where there will be "metadata" (that does not pertain 
> to instance data)  and capabilities that clients want to discover.  YANG 
> library (in itself providing "metadata" about what a server supports and is 
> capable of) is an excellent place to maintain this information.  It also 
> provides the opportunity to be systemic about it, as opposed to requiring 
> everyone to define their own little custom extensions.  
> --- Alex
> 
> > -Original Message-
> > From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> > Sent: Tuesday, February 13, 2018 11:48 AM
> > To: Alexander Clemm <alexander.cl...@huawei.com>
> > Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
> > <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
> > Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> > 
> > Alexander,
> > 
> > I disagree. This YANG Library is mandatory for all implementations; what 
> > you talk
> > about seems to concern only implementations that support YANG push. Hence,
> > this is an extension that should go in its own module.
> > 
> > /js
> > 
> > On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:
> > > Hi,
> > >
> > > I have taken a look at this document.
> > >
> > > My main comment is that one aspect that is missing, that I believe should 
> > > be
> > added, concerns the inclusion of certain metadata about the modules.
> > Specifically, in the context of YANG-Push we had a discussion about being 
> > able to
> > mark nodes that are notifiable on change.  This is just one particular use 
> > case of a
> > more general issue; in YANG-Push after much debate the conclusion was for 
> > now
> > to simply make implementors aware of this issue and advise that a solution 
> > to
> > this must be provided, with the clear understanding that eventually a 
> > standard
> > solution should be defined.
> > >
> > > Since the goal of YANG-Library is to allow clients to find out what is 
> > > actually
> > supported on a given server, this is the right place to keep this 
> > information.  One
> > possible way to address this would be, for a given module, to maintain a 
> > list of
> > "meta-info", with a key "meta-tag", and a list with references to the nodes 
> > to
> > which the metadata applies.  In the case of notifiable-on-change, you would 
> > have
> > a list with one entry "notifiable-on-change", and then the list with the 
> > node
> > definitions to which this tag applies.
> > >
> > > Editorial nit:
> > > 2nd paragraph Introduction: informaton --> information
> > >
> > > Thanks
> > > --- Alex
> > >
> > > From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Mahesh
> > > Jethanandani
> > > Sent: Thursday, February 01, 2018 11:00 AM
> > > To: NETCONF WG <netc...@ietf.org>
> > > Cc: NETMOD WG <netmod@ietf.org>
> > > Subject: [Netconf] LC on YANG Library (bis)
> > >
> > > WG,
> > >
> > > The authors of rfc7895bis have indicated that they believe the document is
> > ready for LC[1].
> > >
> > > This starts a two week LC on the 
> > > draft<https://tools.ietf.org/html/draft-ietf-
> > netconf-rfc7895bis-04>. The LC will end on February 15.
> > >
> > > Please send your comments on this thread. Reviews of the document, and
> > statement of support are particularly helpful to the authors. If you have 
> > concerns
> > about the document, please state those too.
> > >
> > > Authors please indicate if you are aware of any IPR on the document.
> > >
> > > Thanks.
> > >
> > > [1]
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
> > >
> > > Mahesh & Kent
> > >
> > 
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > 
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Alexander Clemm]

Well, we need a general solution for that.  YANG-push is just one use case.  
There are other cases where there will be "metadata" (that does not pertain to 
instance data)  and capabilities that clients want to discover.  YANG library 
(in itself providing "metadata" about what a server supports and is capable of) 
is an excellent place to maintain this information.  It also provides the 
opportunity to be systemic about it, as opposed to requiring everyone to define 
their own little custom extensions.  
--- Alex

> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Tuesday, February 13, 2018 11:48 AM
> To: Alexander Clemm <alexander.cl...@huawei.com>
> Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
> <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> 
> Alexander,
> 
> I disagree. This YANG Library is mandatory for all implementations; what you 
> talk
> about seems to concern only implementations that support YANG push. Hence,
> this is an extension that should go in its own module.
> 
> /js
> 
> On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:
> > Hi,
> >
> > I have taken a look at this document.
> >
> > My main comment is that one aspect that is missing, that I believe should be
> added, concerns the inclusion of certain metadata about the modules.
> Specifically, in the context of YANG-Push we had a discussion about being 
> able to
> mark nodes that are notifiable on change.  This is just one particular use 
> case of a
> more general issue; in YANG-Push after much debate the conclusion was for now
> to simply make implementors aware of this issue and advise that a solution to
> this must be provided, with the clear understanding that eventually a standard
> solution should be defined.
> >
> > Since the goal of YANG-Library is to allow clients to find out what is 
> > actually
> supported on a given server, this is the right place to keep this 
> information.  One
> possible way to address this would be, for a given module, to maintain a list 
> of
> "meta-info", with a key "meta-tag", and a list with references to the nodes to
> which the metadata applies.  In the case of notifiable-on-change, you would 
> have
> a list with one entry "notifiable-on-change", and then the list with the node
> definitions to which this tag applies.
> >
> > Editorial nit:
> > 2nd paragraph Introduction: informaton --> information
> >
> > Thanks
> > --- Alex
> >
> > From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Mahesh
> > Jethanandani
> > Sent: Thursday, February 01, 2018 11:00 AM
> > To: NETCONF WG <netc...@ietf.org>
> > Cc: NETMOD WG <netmod@ietf.org>
> > Subject: [Netconf] LC on YANG Library (bis)
> >
> > WG,
> >
> > The authors of rfc7895bis have indicated that they believe the document is
> ready for LC[1].
> >
> > This starts a two week LC on the 
> > draft<https://tools.ietf.org/html/draft-ietf-
> netconf-rfc7895bis-04>. The LC will end on February 15.
> >
> > Please send your comments on this thread. Reviews of the document, and
> statement of support are particularly helpful to the authors. If you have 
> concerns
> about the document, please state those too.
> >
> > Authors please indicate if you are aware of any IPR on the document.
> >
> > Thanks.
> >
> > [1]
> > https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
> >
> > Mahesh & Kent
> >
> 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Juergen Schoenwaelder]

Alexander,

I disagree. This YANG Library is mandatory for all implementations;
what you talk about seems to concern only implementations that support
YANG push. Hence, this is an extension that should go in its own
module.

/js

On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:
> Hi,
> 
> I have taken a look at this document.
> 
> My main comment is that one aspect that is missing, that I believe should be 
> added, concerns the inclusion of certain metadata about the modules.  
> Specifically, in the context of YANG-Push we had a discussion about being 
> able to mark nodes that are notifiable on change.  This is just one 
> particular use case of a more general issue; in YANG-Push after much debate 
> the conclusion was for now to simply make implementors aware of this issue 
> and advise that a solution to this must be provided, with the clear 
> understanding that eventually a standard solution should be defined.
> 
> Since the goal of YANG-Library is to allow clients to find out what is 
> actually supported on a given server, this is the right place to keep this 
> information.  One possible way to address this would be, for a given module, 
> to maintain a list of "meta-info", with a key "meta-tag", and a list with 
> references to the nodes to which the metadata applies.  In the case of 
> notifiable-on-change, you would have a list with one entry 
> "notifiable-on-change", and then the list with the node definitions to which 
> this tag applies.
> 
> Editorial nit:
> 2nd paragraph Introduction: informaton --> information
> 
> Thanks
> --- Alex
> 
> From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Mahesh 
> Jethanandani
> Sent: Thursday, February 01, 2018 11:00 AM
> To: NETCONF WG 
> Cc: NETMOD WG 
> Subject: [Netconf] LC on YANG Library (bis)
> 
> WG,
> 
> The authors of rfc7895bis have indicated that they believe the document is 
> ready for LC[1].
> 
> This starts a two week LC on the 
> draft. The LC 
> will end on February 15.
> 
> Please send your comments on this thread. Reviews of the document, and 
> statement of support are particularly helpful to the authors. If you have 
> concerns about the document, please state those too.
> 
> Authors please indicate if you are aware of any IPR on the document.
> 
> Thanks.
> 
> [1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
> 
> Mahesh & Kent
> 

> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Alexander Clemm]

Hi,

I have taken a look at this document.

My main comment is that one aspect that is missing, that I believe should be 
added, concerns the inclusion of certain metadata about the modules.  
Specifically, in the context of YANG-Push we had a discussion about being able 
to mark nodes that are notifiable on change.  This is just one particular use 
case of a more general issue; in YANG-Push after much debate the conclusion was 
for now to simply make implementors aware of this issue and advise that a 
solution to this must be provided, with the clear understanding that eventually 
a standard solution should be defined.

Since the goal of YANG-Library is to allow clients to find out what is actually 
supported on a given server, this is the right place to keep this information.  
One possible way to address this would be, for a given module, to maintain a 
list of "meta-info", with a key "meta-tag", and a list with references to the 
nodes to which the metadata applies.  In the case of notifiable-on-change, you 
would have a list with one entry "notifiable-on-change", and then the list with 
the node definitions to which this tag applies.

Editorial nit:
2nd paragraph Introduction: informaton --> information

Thanks
--- Alex

From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Mahesh Jethanandani
Sent: Thursday, February 01, 2018 11:00 AM
To: NETCONF WG 
Cc: NETMOD WG 
Subject: [Netconf] LC on YANG Library (bis)

WG,

The authors of rfc7895bis have indicated that they believe the document is 
ready for LC[1].

This starts a two week LC on the 
draft. The LC 
will end on February 15.

Please send your comments on this thread. Reviews of the document, and 
statement of support are particularly helpful to the authors. If you have 
concerns about the document, please state those too.

Authors please indicate if you are aware of any IPR on the document.

Thanks.

[1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html

Mahesh & Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Kent Watsen]

As co-author, I am not aware of any IPR related to this document.

As a contributor, I have read this document and think that it is ready for 
advancement.

Kent


On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton" 
 on behalf of 
rwil...@cisco.com> wrote:

I am not aware of any IPR related to this document.

Thanks,
Rob

On 01/02/2018 18:59, Mahesh Jethanandani wrote:
WG,

The authors of rfc7895bis have indicated that they believe the document is 
ready for LC[1].

This starts a two week LC on the 
draft.
 The LC will end on February 15.

Please send your comments on this thread. Reviews of the document, and 
statement of support are particularly helpful to the authors. If you have 
concerns about the document, please state those too.

Authors please indicate if you are aware of any IPR on the document.

Thanks.

[1] 
https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html

Mahesh & Kent





___

Netconf mailing list

netc...@ietf.org

https://www.ietf.org/mailman/listinfo/netconf


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Robert Wilton]

I am not aware of any IPR related to this document.

Thanks,
Rob


On 01/02/2018 18:59, Mahesh Jethanandani wrote:

WG,

The authors of rfc7895bis have indicated that they believe the 
document is ready for LC[1].


This starts a two week LC on the draft 
. The LC 
will end on February 15.


Please send your comments on this thread. Reviews of the document, and 
statement of support are particularly helpful to the authors. If you 
have concerns about the document, please state those too.


Authors please indicate if you are aware of any IPR on the document.

Thanks.

[1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html

Mahesh & Kent



___
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Andy Bierman]

On Thu, Feb 1, 2018 at 10:59 AM, Mahesh Jethanandani <
mjethanand...@gmail.com> wrote:

> WG,
>
> The authors of rfc7895bis have indicated that they believe the document is
> ready for LC[1].
>
> This starts a two week LC on the draft
> . The LC
> will end on February 15.
>
> Please send your comments on this thread. Reviews of the document, and
> statement of support are particularly helpful to the authors. If you have
> concerns about the document, please state those too.
>
> Authors please indicate if you are aware of any IPR on the document.
>
>
I am not aware of any IPR related to this document.



> Thanks.
>
> [1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>
> Mahesh & Kent
>
>

Andy


>
> ___
> Netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Martin Bjorklund]

Mahesh Jethanandani  wrote:
> WG,
> 
> The authors of rfc7895bis have indicated that they believe the
> document is ready for LC[1].
> 
> This starts a two week LC on the draft
> . The LC
> will end on February 15.
> 
> Please send your comments on this thread. Reviews of the document, and
> statement of support are particularly helpful to the authors. If you
> have concerns about the document, please state those too.
> 
> Authors please indicate if you are aware of any IPR on the document.

I am not aware of any IPR related to this document.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Juergen Schoenwaelder]

On Thu, Feb 01, 2018 at 10:59:47AM -0800, Mahesh Jethanandani wrote:
> 
> Authors please indicate if you are aware of any IPR on the document.
> 

I am not.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod