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

2018-02-15 Thread 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 ; Juergen
> Schoenwaelder 
> Cc: NETCONF WG ; NETMOD WG 
> 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 
> > Cc: Mahesh Jethanandani ; NETCONF WG
> > ; NETMOD WG 
> > 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 
> > > 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 > > f.org_html_draft-2Dietf-
> 2D=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-nd
> > >
> b3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=oAL
> b7L
> > >
> KrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA=NaY8R9DBhInZQAxL35_KjFze
> YHfy
> > > TOVJLnMHAKGeKF0=
> > 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_ma
> > > il-
> 2Darchive_web_netconf_current_msg13980.html=DwICAg=HAkYuh63rs
> > > uhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGT
> > >
>

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

2018-02-15 Thread 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)

2018-02-15 Thread 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)

2018-02-15 Thread 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)

2018-02-15 Thread 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)

2018-02-15 Thread 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)

2018-02-15 Thread 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 
> Cc: Mahesh Jethanandani ; NETCONF WG
> ; NETMOD WG 
> 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 
> > 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 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=GPdqlio_2laQl93jobGXgXOs-WpouxE1W4MeGxvh558=
> 
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>

Re: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01

2018-02-15 Thread Lou Berger 

All,

    The adoption call for this document closed on Feb 8th.

Authors,

Please repost your document with only the 'filename' and date updated as 
draft-ietf-netmod-yang-data-ext-00. Please discuss on list any comments 
received during the adoption call and then capture the results of the 
discussions in the -01 rev. Finally, I believe the -01 rev should 
indicate that the document updates RFC8040.


Thank you,

Lou (and co-chairs)


On 1/25/2018 8:26 AM, Lou Berger wrote:

Hi,

This is the start of a *two* week poll on making
draft-bierman-netmod-yang-data-ext a working group document. Please send
email to the list indicating "yes/support" or "no/do not support".  If
indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

This poll ends on February 8.

Thank you!

Lou (and Co-chairs)

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



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