date:20180117

Lou Berger  wrote:
> 
> 
> On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> ...
> >>> My main concern is actually the YL version.  I strongly think SM need
> >>> to use YL-bis rather that the old YL, so that it can support NMDA.
> >>>
> >> Right now to SM is independent of Yang Library version and can run
> >> with either.
> > No this is not correct.  SM uses a grouping from the old YANG
> > library (for the "use-schema" case),
> I thought YLbis was an updat e to UL (i.e., no name change) as such SM
> can include either.

The old "modules-state" structure is deprecated, and a new structure
that allows multiple datastores is defined.  Note that YLbis can be
used by both NMDA-capabale and non-NMDA-capabale servers.

> >   and talks about mounting
> > "modules-state" ("inline" case).
> In informative descriptions only.  Certainly these can be changed to
> allow for YL-bis if need be.
> 
> >> I certainly would expect use of Yang Library bis and nmda
> >> to have advantages.
> >>
> >>> The implementation effort for supporting the new YL in clients and
> >>> servers is minimal, esp. when compared to the efforts involved in
> >>> supporting SM.
> >>>
> >>> Adding an indirection is (for me) less important, but it has the
> >>> benefit of solving the two issues (a) and (b) above, and I haven't
> >>> seen any technical problem with it.
> >>>
> >> (A) has implementation implications and those participating in the
> >> discussion at the time expressed as not being worth the cost.
> >> I don't believe b was seen as a significant issue either.
> >>
> >>> Do you have any technical concerns with using an annotation as an
> >>> indirection?
> >>>
> >> The technicsl issue I have with the approaches the same one that was
> >> raised when debated previously, ie the implementation overhead of
> >> requiring inline schemas to be available at the top level.
> > Ok.  I'm ok with keeping the inline case as it is.  However, I think
> > we need to use the new YL-bis, so that we can support the NMDA.
> Given that NMDA support is not yet fully defined, we're still in the
> transition period where support for both NMDA and non-NMDA
> implementations need to be considered.  Rob presented some options
> earlier in the thread that I think captures this.

Again, note that YLbis supports both NMDA and non-NMDA servers.

Also note that YLbis is just a different read-only monitoring
structure.  Given an implementation that supports the old YL, it is
trivial to add support for YLbis (especially compared to the more than
non-trivial amount of work required to support schema mount...).


/martin

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

2018-01-17 Thread Eliot Lear



On 18.01.18 01:25, Sonal Agarwal wrote:
> Hi Kent,
>
> The last remaining open issue is about adding containers for addresses
> (source, destination) and ports (source, destination). A user has the
> choice to use the container or leaf for address (source/dest) and port
> (source/dest).  With this, the user can use the Yang model to configure
> scale ACL's.
>
> I did some preliminary work on this in August/September last year, but ran
> out of time to explore this fully as I had to upload my other changes by
> particular dates.
>
> The non implementation of this does not detract from the usability of the
> ACL model.
>
> Closing the issue to completion will require me to revisit and implement
> the yang solution for container support in the model.

+1 and I would go further.  Adding this makes the model even more
complex for the simpler cases.  If someone is looking to save memory
through such a feature (assuming that it even does), it can be done
below this abstraction layer.

Eliot




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

2018-01-17 Thread Mahesh Jethanandani

The important thing to note is that the current model does not prevent ACEs 
from being configured for each ACL, like most configurations that exist today. 
As Acee mentions in his e-mail, scaling can be done programmatically also.

Object groups (or containers) are another way to organize rules that constitute 
an ACE. And object groups can contain other object groups. Instead of having an 
ACL with a list of rules, one could have an ACL that refers to an object group 
that contains the rules. And multiple ACL can refer to the same object group.

If there is a strong desire for the feature, the authors believe that this can 
be addressed in the next version of the *RFC*, probably as a bis document 
(sorry, if I was not clear what I meant by “next version”).

Looking at RFC 7950, I see that we can update the model in a backward 
compatible way, by adding a ‘case’ statement. How about adding a ‘choice’ 
statement? Would that be backward compatible? If not, we can make an editorial 
change to add the ‘choice’ statement in the model today, and later in the bis 
document add the ‘case’ statement for object groups.

Cheers.

> On Jan 17, 2018, at 4:25 PM, Sonal Agarwal  wrote:
> 
> Hi Kent,
> 
> The last remaining open issue is about adding containers for addresses 
> (source, destination) and ports (source, destination). A user has the choice 
> to use the container or leaf for address (source/dest) and port 
> (source/dest).  With this, the user can use the Yang model to configure scale 
> ACL's.
> 
> I did some preliminary work on this in August/September last year, but ran 
> out of time to explore this fully as I had to upload my other changes by 
> particular dates.
> 
> The non implementation of this does not detract from the usability of the ACL 
> model.
> 
> Closing the issue to completion will require me to revisit and implement the 
> yang solution for container support in the model.
> 
> Thanks,
> Sonal.
> 
> 
> On Wed, Jan 17, 2018 at 3:33 PM, Kent Watsen  > wrote:
> 
> H Mahesh,
> 
> >> - There is an open issue in the document (section 8) - are we going
> >>  to resolve that during WG last call or is this a leftover?
> >
> > This will be resolved in the next version of the module. It is
> > documented under Issues tab in GitHub. Should we remove it from
> > the draft?
> 
> Most of Juergen's comments are editorial in nature and can truly be handled 
> as part of the LC process, but this open issue has me worried, as it may 
> result in a significant technical change.
> 
> What will it take to close this open issue?  Is it just a matter of the 
> getting the WG to agree that it's not an issue, or do we already know that it 
> is a real issue and only the solution is pending?
> 
> Thanks,
> Kent
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 
> 

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

2018-01-17 Thread Acee Lindem (acee)

Hi Sonal,

From: netmod > on 
behalf of Sonal Agarwal >
Date: Wednesday, January 17, 2018 at 7:25 PM
To: Kent Watsen >
Cc: "netmod@ietf.org" 
>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

Hi Kent,

The last remaining open issue is about adding containers for addresses (source, 
destination) and ports (source, destination). A user has the choice to use the 
container or leaf for address (source/dest) and port (source/dest).  With this, 
the user can use the Yang model to configure scale ACL's.

Is this is the motivation for doing it two ways? I’d think that aggregation of 
common match criteria for scale could be better done programmatically than 
through prudent configuration.

Thanks,
Acee

I did some preliminary work on this in August/September last year, but ran out 
of time to explore this fully as I had to upload my other changes by particular 
dates.

The non implementation of this does not detract from the usability of the ACL 
model.

Closing the issue to completion will require me to revisit and implement the 
yang solution for container support in the model.

Thanks,
Sonal.

On Wed, Jan 17, 2018 at 3:33 PM, Kent Watsen 
> wrote:

H Mahesh,

>> - There is an open issue in the document (section 8) - are we going
>>  to resolve that during WG last call or is this a leftover?
>
> This will be resolved in the next version of the module. It is
> documented under Issues tab in GitHub. Should we remove it from
> the draft?

Most of Juergen's comments are editorial in nature and can truly be handled as 
part of the LC process, but this open issue has me worried, as it may result in 
a significant technical change.

What will it take to close this open issue?  Is it just a matter of the getting 
the WG to agree that it's not an issue, or do we already know that it is a real 
issue and only the solution is pending?

Thanks,
Kent

___
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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

2018-01-17 Thread Sonal Agarwal

Hi Kent,

The last remaining open issue is about adding containers for addresses
(source, destination) and ports (source, destination). A user has the
choice to use the container or leaf for address (source/dest) and port
(source/dest).  With this, the user can use the Yang model to configure
scale ACL's.

I did some preliminary work on this in August/September last year, but ran
out of time to explore this fully as I had to upload my other changes by
particular dates.

The non implementation of this does not detract from the usability of the
ACL model.

Closing the issue to completion will require me to revisit and implement
the yang solution for container support in the model.

Thanks,
Sonal.

On Wed, Jan 17, 2018 at 3:33 PM, Kent Watsen  wrote:

>
> H Mahesh,
>
> >> - There is an open issue in the document (section 8) - are we going
> >>  to resolve that during WG last call or is this a leftover?
> >
> > This will be resolved in the next version of the module. It is
> > documented under Issues tab in GitHub. Should we remove it from
> > the draft?
>
> Most of Juergen's comments are editorial in nature and can truly be
> handled as part of the LC process, but this open issue has me worried, as
> it may result in a significant technical change.
>
> What will it take to close this open issue?  Is it just a matter of the
> getting the WG to agree that it's not an issue, or do we already know that
> it is a real issue and only the solution is pending?
>
> Thanks,
> Kent
>
>
>
>
> ___
> 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

Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

2018-01-17 Thread Alexander Clemm

Thanks, Rob and Juergen, for pointing this out!

I guess we should add this to the text as well.

--- Alex

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: Wednesday, January 17, 2018 2:43 PM
To: Alexander Clemm ; Einar Nilsen-Nygaard 
(einarnn) ; netmod@ietf.org
Subject: Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and 
default values and RFC 6243

HI Alex,

Note, that when it comes to the NMDA  datastore there are no 
default values.  Only the values that are "in use".
Thanks,
Rob

On 17/01/2018 19:09, Alexander Clemm wrote:
Hi Einar,

I suggest we add clarification that default values must be reported.  For 
on-change, clearly all changes need to be reported, whether the change is to a 
default value or not, everything else would be confusing.  Also for periodic, 
it would be confusing to leave out readings when a value is at default  versus 
not (the object might also have been deleted, etc).  So, I don’t think we need 
to add a flag or such that would allow to exclude defaults which appear to be 
of limited benefit to applications while introducing a lot more complexity to 
deal with corner cases such as the ones described.

--- Alex

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Einar Nilsen-Nygaard 
(einarnn)
Sent: Wednesday, January 17, 2018 5:27 AM
To: netmod@ietf.org
Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default 
values and RFC 6243

All,

In discussions with some customers and on implementation, the issue of defaults 
has come up. For get/get-config we have the “with defaults capability” defined 
in RFC 6243 that allows us to control the behaviour with respect to defaults. 
To remind folk with an example, we could have:

  http://example.com/ns/interfaces"/>

  report-all

The addition of the “with-defaults” tag and value determines the behavior of 
the get in this example (taken from A.3.1 in RFC 
6243).

It strikes me that we need to have a similar mechanism for telemetry, allowing 
a user to specify, for example, that for a periodic subscription on a subtree, 
they also wish default values to be reported. I think at minimum we need 
clarification on this, as section 3.7 of draft-ietf-netconf-yang-push-12 
currently says:

The content of the update record is equivalent to the contents that would be 
obtained had the same data been explicitly retrieved using e.g., a NETCONF 
"get" operation, with the same filters applied.

This text can currently only refer to a “get” as defined in RFC 6241 as there 
is no reference to RFC 6243 as yet. I think we need to address this issue now 
to define expectations, even if it is to explicitly not consider an RFC 
6243-like mechanism or to say that we only consider explicitly set values in 
telemetry, or…

Cheers,

Einar

___

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15


H Mahesh,

>> - There is an open issue in the document (section 8) - are we going
>>  to resolve that during WG last call or is this a leftover?
>
> This will be resolved in the next version of the module. It is
> documented under Issues tab in GitHub. Should we remove it from
> the draft?

Most of Juergen's comments are editorial in nature and can truly be handled as 
part of the LC process, but this open issue has me worried, as it may result in 
a significant technical change.  

What will it take to close this open issue?  Is it just a matter of the getting 
the WG to agree that it's not an issue, or do we already know that it is a real 
issue and only the solution is pending?

Thanks,
Kent




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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

2018-01-17 Thread Sonal Agarwal

I am not aware of any IPR impacting this draft.

> On Jan 17, 2018, at 1:55 PM, Kent Watsen  wrote:
> 
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-15.
> 
> This working group last call ends on January 31st.
> Please send your comments to the NETMOD mailing list.
> 
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Also, could the authors, explicitly CC-ed on this email,
> please confirm at this time that they are unaware of
> any IPR related to this draft.
> 
> Thank you,
> NETMOD Chairs
> 

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

2018-01-17 Thread Mahesh Jethanandani



> On Jan 17, 2018, at 2:49 PM, Juergen Schoenwaelder 
>  wrote:
> 
> Paging through the document, I found the following:
> 
> - The main module uses YANG 1.1, others modules use YANG 1.0. I think
>  it makes sense to generally use YANG 1.1. (The packet header module
>  may not need YANG 1.1 but then the main module is YANG 1.1 anyway.)

Will update.

> 
> - Since YANG 1.1 is used, the references to RFC6020 should be replaced
>  with references to RFC 7950.

Will update.

> 
> - The security consideration needs to be updated to follow the newer
>  template (which also covers RESTCONF).

Will add.

> 
> - There is an open issue in the document (section 8) - are we going
>  to resolve that during WG last call or is this a leftover?

This will be resolved in the next version of the module. It is documented under 
Issues tab in GitHub. Should we remove it from the draft?

> 
> - There are references to RFCs in the YANG modules (in reference
>  statement) that must also be listed in the text and added to the
>  references section. This is why you usually find text of the form
> 
>This YANG module imports types from [RFC...] and references
>[RFC...], [RFC...], and [RFC…].

Will add.

> 
> /js
> 
> On Wed, Jan 17, 2018 at 09:55:04PM +, Kent Watsen wrote:
>> All,
>> 
>> This starts a two-week working group last call on
>> draft-ietf-netmod-acl-model-15.
>> 
>> This working group last call ends on January 31st.
>> Please send your comments to the NETMOD mailing list.
>> 
>> Positive comments, e.g., "I've reviewed this document
>> and believe it is ready for publication", are welcome!
>> This is useful and important, even from authors.
>> 
>> Also, could the authors, explicitly CC-ed on this email,
>> please confirm at this time that they are unaware of
>> any IPR related to this draft.
>> 
>> Thank you,
>> NETMOD Chairs
>> 
>> ___
>> 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

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

Paging through the document, I found the following:

- The main module uses YANG 1.1, others modules use YANG 1.0. I think
  it makes sense to generally use YANG 1.1. (The packet header module
  may not need YANG 1.1 but then the main module is YANG 1.1 anyway.)

- Since YANG 1.1 is used, the references to RFC6020 should be replaced
  with references to RFC 7950.

- The security consideration needs to be updated to follow the newer
  template (which also covers RESTCONF).

- There is an open issue in the document (section 8) - are we going
  to resolve that during WG last call or is this a leftover?

- There are references to RFCs in the YANG modules (in reference
  statement) that must also be listed in the text and added to the
  references section. This is why you usually find text of the form

This YANG module imports types from [RFC...] and references
[RFC...], [RFC...], and [RFC...].

/js

On Wed, Jan 17, 2018 at 09:55:04PM +, Kent Watsen wrote:
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-15.
> 
> This working group last call ends on January 31st.
> Please send your comments to the NETMOD mailing list.
> 
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Also, could the authors, explicitly CC-ed on this email,
> please confirm at this time that they are unaware of
> any IPR related to this draft.
> 
> Thank you,
> NETMOD Chairs
> 
> ___
> 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] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243


HI Alex,

Note, that when it comes to the NMDA  datastore there are 
no default values.  Only the values that are "in use".


Thanks,
Rob


On 17/01/2018 19:09, Alexander Clemm wrote:


Hi Einar,

I suggest we add clarification that default values must be reported.  
For on-change, clearly all changes need to be reported, whether the 
change is to a default value or not, everything else would be 
confusing.  Also for periodic, it would be confusing to leave out 
readings when a value is at default  versus not (the object might also 
have been deleted, etc).  So, I don’t think we need to add a flag or 
such that would allow to exclude defaults which appear to be of 
limited benefit to applications while introducing a lot more 
complexity to deal with corner cases such as the ones described.


--- Alex

*From:*netmod [mailto:netmod-boun...@ietf.org] *On Behalf Of *Einar 
Nilsen-Nygaard (einarnn)

*Sent:* Wednesday, January 17, 2018 5:27 AM
*To:* netmod@ietf.org
*Subject:* [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 
and default values and RFC 6243


All,

In discussions with some customers and on implementation, the issue of 
defaults has come up. For get/get-config we have the “with defaults 
capability” defined in RFC 6243 that allows us to control the 
behaviour with respect to defaults. To remind folk with an example, we 
could have:




  

    

      http://example.com/ns/interfaces"/>

    

    

      report-all

    

  



The addition of the “with-defaults” tag and value determines the 
behavior of the get in this example (taken from A.3.1 in RFC 6243 
).


It strikes me that we need to have a similar mechanism for telemetry, 
allowing a user to specify, for example, that for a periodic 
subscription on a subtree, they also wish default values to be 
reported. I think at minimum we need clarification on this, as section 
3.7 of draft-ietf-netconf-yang-push-12 currently says:


/The content of the update record is equivalent to the contents
that would be obtained had the same data been explicitly retrieved
using e.g., a NETCONF "get" operation, with the same filters applied./

This text can currently only refer to a “get” as defined in RFC 6241 
as there is no reference to RFC 6243 as yet. I think we need to 
address this issue now to define expectations, even if it is to 
explicitly not consider an RFC 6243-like mechanism or to say that we 
only consider explicitly set values in telemetry, or…


Cheers,

Einar



___
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

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts


I'm not aware of any IPR impacting either of these two drafts.

Rob


On 17/01/2018 19:02, Kent Watsen wrote:

I'm not aware of any IPR impacting either of these two drafts.

Kent // as co-author


= original message =

The authors of draft-ietf-netconf-nmda-netconf and 
draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. Please 
send your comments on this thread. Comments like “I have reviewed the documents 
and believe they are ready for publication”, or “I have concerns about the 
document because …” are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of the 
drafts.

Thanks.

Mahesh & Kent

___
Netconf mailing list
netc...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=YD0IXtUkMMI3qIK63vNpsDmumHSc_7n1T6esiz6Nzhc=5dIbx4-7CM-5NmbIyhGS16He41fyV_CoCuTLBV0mDLw=


___
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

Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

On Wed, Jan 17, 2018 at 09:17:24PM +, Einar Nilsen-Nygaard (einarnn) wrote:
> Juergen,
> 
> Thanks for that! That is a useful note, and it can reduce the problem space 
> here, and I’m fine with that. As you may have seen from my response, though, 
> my main concerns is about configuration.
> 
> Remind me — under NMDA will configuration leaves be reported back via 
> “operational datastores”? Meaning that default configuration data is expected 
> to always be returned when accessed via an “operational datastore”. Apologies 
> if this is a dumb question, but I’ve not been able to track NMDA close enough 
> to answer this question immediately.
>

With NMDA, you have the (short) configuration of the interface lo in
 and once this has been applied, you have the (possibly long)
applied configuration and state of the interface lo in .

/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

[netmod] WG Last Call: draft-ietf-netmod-acl-model-15

All,

This starts a two-week working group last call on
draft-ietf-netmod-acl-model-15.

This working group last call ends on January 31st.
Please send your comments to the NETMOD mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Also, could the authors, explicitly CC-ed on this email,
please confirm at this time that they are unaware of
any IPR related to this draft.

Thank you,
NETMOD Chairs

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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt


Yes, good job Mahesh and team!

My previous Last Call closing message [1] said that we'd evaluate if that Last 
Call was successful or not based on the result of the ensuing discussion 
regarding the model's structure.  As the diff [2] for this update shows, the 
draft has changed significantly since then, such that I think that another Last 
Call is needed.  I will start it now.

[1] https://mailarchive.ietf.org/arch/msg/netmod/lX4LBQTfNp3grwDX1-KNvsuEI9E
[2] https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15

Kent // shepherd



= original message =

Thank you Mahesh for taking everyone's feedback, showing a lot of
patience, and having to do this under what can only be described as
trying circumstances.  May I now ask the chairs what their next step
is?  This draft was intended to be in response to LC comments.

Eliot


On 17.01.18 04:17, Mahesh Jethanandani wrote:
> This version of the drafts addresses comments received during the last run of 
> the LC. We, the authors, believe that this document is ready for LC.
>
>> On Jan 16, 2018, at 7:11 PM, internet-dra...@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Network Modeling WG of the IETF.
>>
>>Title   : Network Access Control List (ACL) YANG Data Model
>>Authors : Mahesh Jethanandani
>>  Lisa Huang
>>  Sonal Agarwal
>>  Dana Blair
>>  Filename: draft-ietf-netmod-acl-model-15.txt
>>  Pages   : 51
>>  Date: 2018-01-16
>>
>> Abstract:
>>   This document describes a data model of Access Control List (ACL)
>>   basic building blocks.
>>
>>   Editorial Note (To be removed by RFC Editor)
>>
>>   This draft contains many placeholder values that need to be replaced
>>   with finalized values at the time of publication.  This note
>>   summarizes all of the substitutions that are needed.  Please note
>>   that no other RFC Editor instructions are specified anywhere else in
>>   this document.
>>
>>   Artwork in this document contains shorthand references to drafts in
>>   progress.  Please apply the following replacements
>>
>>   o  "" --> the assigned RFC value for this draft both in this
>>  draft and in the YANG models under the revision statement.
>>
>>   o  Revision date in model needs to get updated with the date the
>>  draft gets approved.  The date also needs to get reflected on the
>>  line with .
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
> ___
> 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

Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

2018-01-17 Thread Einar Nilsen-Nygaard (einarnn)

Juergen,

Thanks for that! That is a useful note, and it can reduce the problem space 
here, and I’m fine with that. As you may have seen from my response, though, my 
main concerns is about configuration.

Remind me — under NMDA will configuration leaves be reported back via 
“operational datastores”? Meaning that default configuration data is expected 
to always be returned when accessed via an “operational datastore”. Apologies 
if this is a dumb question, but I’ve not been able to track NMDA close enough 
to answer this question immediately.

Cheers,

Einar

> On 17 Jan 2018, at 20:44, Juergen Schoenwaelder 
>  wrote:
> 
> For what its worth, the NMDA documents for NETCONF and RESTCONF posted
> today state that with-defaults only applies to non-operational
> datastores and that values are always reported for operational
> datastores, regardless whether they match any defaults.
> 
> /js
> 
> On Wed, Jan 17, 2018 at 07:09:52PM +, Alexander Clemm wrote:
>> Hi Einar,
>> 
>> I suggest we add clarification that default values must be reported.  For 
>> on-change, clearly all changes need to be reported, whether the change is to 
>> a default value or not, everything else would be confusing.  Also for 
>> periodic, it would be confusing to leave out readings when a value is at 
>> default  versus not (the object might also have been deleted, etc).  So, I 
>> don’t think we need to add a flag or such that would allow to exclude 
>> defaults which appear to be of limited benefit to applications while 
>> introducing a lot more complexity to deal with corner cases such as the ones 
>> described.
>> 
>> --- Alex
>> 
>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Einar 
>> Nilsen-Nygaard (einarnn)
>> Sent: Wednesday, January 17, 2018 5:27 AM
>> To: netmod@ietf.org
>> Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and 
>> default values and RFC 6243
>> 
>> All,
>> 
>> In discussions with some customers and on implementation, the issue of 
>> defaults has come up. For get/get-config we have the “with defaults 
>> capability” defined in RFC 6243 that allows us to control the behaviour with 
>> respect to defaults. To remind folk with an example, we could have:
>> 
>>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>  
>>
>>  http://example.com/ns/interfaces"/>
>>
>>> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
>>  report-all
>>
>>  
>>
>> 
>> The addition of the “with-defaults” tag and value determines the behavior of 
>> the get in this example (taken from A.3.1 in RFC 
>> 6243).
>> 
>> It strikes me that we need to have a similar mechanism for telemetry, 
>> allowing a user to specify, for example, that for a periodic subscription on 
>> a subtree, they also wish default values to be reported. I think at minimum 
>> we need clarification on this, as section 3.7 of 
>> draft-ietf-netconf-yang-push-12 currently says:
>> 
>> The content of the update record is equivalent to the contents that would be 
>> obtained had the same data been explicitly retrieved using e.g., a NETCONF 
>> "get" operation, with the same filters applied.
>> 
>> This text can currently only refer to a “get” as defined in RFC 6241 as 
>> there is no reference to RFC 6243 as yet. I think we need to address this 
>> issue now to define expectations, even if it is to explicitly not consider 
>> an RFC 6243-like mechanism or to say that we only consider explicitly set 
>> values in telemetry, or…
>> 
>> Cheers,
>> 
>> Einar
>> 
> 
>> ___
>> 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] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

For what its worth, the NMDA documents for NETCONF and RESTCONF posted
today state that with-defaults only applies to non-operational
datastores and that values are always reported for operational
datastores, regardless whether they match any defaults.

/js

On Wed, Jan 17, 2018 at 07:09:52PM +, Alexander Clemm wrote:
> Hi Einar,
> 
> I suggest we add clarification that default values must be reported.  For 
> on-change, clearly all changes need to be reported, whether the change is to 
> a default value or not, everything else would be confusing.  Also for 
> periodic, it would be confusing to leave out readings when a value is at 
> default  versus not (the object might also have been deleted, etc).  So, I 
> don’t think we need to add a flag or such that would allow to exclude 
> defaults which appear to be of limited benefit to applications while 
> introducing a lot more complexity to deal with corner cases such as the ones 
> described.
> 
> --- Alex
> 
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Einar 
> Nilsen-Nygaard (einarnn)
> Sent: Wednesday, January 17, 2018 5:27 AM
> To: netmod@ietf.org
> Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and 
> default values and RFC 6243
> 
> All,
> 
> In discussions with some customers and on implementation, the issue of 
> defaults has come up. For get/get-config we have the “with defaults 
> capability” defined in RFC 6243 that allows us to control the behaviour with 
> respect to defaults. To remind folk with an example, we could have:
> 
>   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>   
> 
>   http://example.com/ns/interfaces"/>
> 
>   xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
>   report-all
> 
>   
> 
> 
> The addition of the “with-defaults” tag and value determines the behavior of 
> the get in this example (taken from A.3.1 in RFC 
> 6243).
> 
> It strikes me that we need to have a similar mechanism for telemetry, 
> allowing a user to specify, for example, that for a periodic subscription on 
> a subtree, they also wish default values to be reported. I think at minimum 
> we need clarification on this, as section 3.7 of 
> draft-ietf-netconf-yang-push-12 currently says:
> 
> The content of the update record is equivalent to the contents that would be 
> obtained had the same data been explicitly retrieved using e.g., a NETCONF 
> "get" operation, with the same filters applied.
> 
> This text can currently only refer to a “get” as defined in RFC 6241 as there 
> is no reference to RFC 6243 as yet. I think we need to address this issue now 
> to define expectations, even if it is to explicitly not consider an RFC 
> 6243-like mechanism or to say that we only consider explicitly set values in 
> telemetry, or…
> 
> Cheers,
> 
> Einar
> 

> ___
> 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] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

2018-01-17 Thread Einar Nilsen-Nygaard (einarnn)



On 17 Jan 2018, at 19:09, Alexander Clemm 
> wrote:

Hi Einar,

I suggest we add clarification that default values must be reported.

einarnn> I’m afraid I do not agree with that, especially when it comes to 
configuration leaves. Platforms can have vast numbers of configuration defaults 
that they run with when the end user makes a relatively simple configuration 
change. Take the example of creating  a loopback interface on IOS-XE. If we 
look at the defaults for that, we would have over 60 default leaves that would 
be reported if a subscription was established on that interface…even though the 
explicit end-user config may only be a couple of leaves, say description and an 
IPv4 address

For on-change, clearly all changes need to be reported, whether the change is 
to a default value or not, everything else would be confusing.

einarnn> I agree that a change to or away from the default value needs to be 
reported. And I can also agree that if a default value is explicitly set by an 
end user, then that default value should be reported on an ongoing basis.

einarnn> As you can see, my primary concerns are about configuration data. As 
yet, I haven’t thought so much about the implications on config false data.

Also for periodic, it would be confusing to leave out readings when a value is 
at default  versus not (the object might also have been deleted, etc).

einarnn> For config, I don’t agree.

So, I don’t think we need to add a flag or such that would allow to exclude 
defaults which appear to be of limited benefit to applications while 
introducing a lot more complexity to deal with corner cases such as the ones 
described.

einarnn> And I still do not agree, especially when configuration may have a 
large number of default settings that are relatively uninteresting in terms of 
reporting when one puts in place telemetry. After all, the consumer knows what 
the defaults are from the model. Why send all that data that, typically, a 
platform will need to work harder to extract.

einarnn> I think this is an important issue, or I wouldn’t have raised it, but 
I am strongly opposed to making the behavior of telemetry the equivalent of RFC 
6243 “report-all” behavior.

Cheers,

Einar


--- Alex

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Einar Nilsen-Nygaard 
(einarnn)
Sent: Wednesday, January 17, 2018 5:27 AM
To: netmod@ietf.org
Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default 
values and RFC 6243

All,

In discussions with some customers and on implementation, the issue of defaults 
has come up. For get/get-config we have the “with defaults capability” defined 
in RFC 6243 that allows us to control the behaviour with respect to defaults. 
To remind folk with an example, we could have:


  

  http://example.com/ns/interfaces"/>


  report-all

  


The addition of the “with-defaults” tag and value determines the behavior of 
the get in this example (taken from A.3.1 in RFC 
6243).

It strikes me that we need to have a similar mechanism for telemetry, allowing 
a user to specify, for example, that for a periodic subscription on a subtree, 
they also wish default values to be reported. I think at minimum we need 
clarification on this, as section 3.7 of draft-ietf-netconf-yang-push-12 
currently says:

The content of the update record is equivalent to the contents that would be 
obtained had the same data been explicitly retrieved using e.g., a NETCONF 
"get" operation, with the same filters applied.

This text can currently only refer to a “get” as defined in RFC 6241 as there 
is no reference to RFC 6243 as yet. I think we need to address this issue now 
to define expectations, even if it is to explicitly not consider an RFC 
6243-like mechanism or to say that we only consider explicitly set values in 
telemetry, or…

Cheers,

Einar

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

Re: [netmod] schema mount and YANG library

On Wed, 2018-01-17 at 14:14 -0500, Lou Berger wrote:
> 
> On 1/17/2018 11:57 AM, Ladislav Lhotka wrote:
> > > > > Ok.  I'm ok with keeping the inline case as it is.  However, I think
> > > > 
> > > > I don't agree. The metadata annotation solves real issues.
> > > 
> > > One issue with the annotation is that since the schema might be
> > > different in different datastores, it means that the client needs to
> > > read the annotation in all datastores, and then fetch the schemas.  So
> > > it is a bit more difficult to work with for a client.
> > 
> > But it doesn't mean that the schemas*must*  be different, and it is easy to
> > figure out when they are the same. Also, modules sets in YLbis can further
> > help
> > avoid redundant parsing of the same modules.
> > 
> > Lada
> > 
> 
> So I think this amplifies that the difference is one of optimization.   
> Given the maturity of this work and the state of the dependent work, 
> some of which is already with IESG for publication - I don't see how or 
> why we should be discussing anything more than fixing flaws in this 
> document.

I beg to differ.

Lada

> 
> Lou
> 
-- 
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] I-D Action: draft-ietf-netmod-acl-model-15.txt

2018-01-17 Thread Eliot Lear

Thank you Mahesh for taking everyone's feedback, showing a lot of
patience, and having to do this under what can only be described as
trying circumstances.  May I now ask the chairs what their next step
is?  This draft was intended to be in response to LC comments.

Eliot


On 17.01.18 04:17, Mahesh Jethanandani wrote:
> This version of the drafts addresses comments received during the last run of 
> the LC. We, the authors, believe that this document is ready for LC.
>
>> On Jan 16, 2018, at 7:11 PM, internet-dra...@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Network Modeling WG of the IETF.
>>
>>Title   : Network Access Control List (ACL) YANG Data Model
>>Authors : Mahesh Jethanandani
>>  Lisa Huang
>>  Sonal Agarwal
>>  Dana Blair
>>  Filename: draft-ietf-netmod-acl-model-15.txt
>>  Pages   : 51
>>  Date: 2018-01-16
>>
>> Abstract:
>>   This document describes a data model of Access Control List (ACL)
>>   basic building blocks.
>>
>>   Editorial Note (To be removed by RFC Editor)
>>
>>   This draft contains many placeholder values that need to be replaced
>>   with finalized values at the time of publication.  This note
>>   summarizes all of the substitutions that are needed.  Please note
>>   that no other RFC Editor instructions are specified anywhere else in
>>   this document.
>>
>>   Artwork in this document contains shorthand references to drafts in
>>   progress.  Please apply the following replacements
>>
>>   o  "" --> the assigned RFC value for this draft both in this
>>  draft and in the YANG models under the revision statement.
>>
>>   o  Revision date in model needs to get updated with the date the
>>  draft gets approved.  The date also needs to get reflected on the
>>  line with .
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] schema mount and YANG library




On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
...

My main concern is actually the YL version.  I strongly think SM need
to use YL-bis rather that the old YL, so that it can support NMDA.


Right now to SM is independent of Yang Library version and can run
with either.

No this is not correct.  SM uses a grouping from the old YANG
library (for the "use-schema" case),
I thought YLbis was an updat e to UL (i.e., no name change) as such SM 
can include either.



  and talks about mounting
"modules-state" ("inline" case).
In informative descriptions only.  Certainly these can be changed to 
allow for YL-bis if need be.



I certainly would expect use of Yang Library bis and nmda
to have advantages.


The implementation effort for supporting the new YL in clients and
servers is minimal, esp. when compared to the efforts involved in
supporting SM.

Adding an indirection is (for me) less important, but it has the
benefit of solving the two issues (a) and (b) above, and I haven't
seen any technical problem with it.


(A) has implementation implications and those participating in the
discussion at the time expressed as not being worth the cost.
I don't believe b was seen as a significant issue either.


Do you have any technical concerns with using an annotation as an
indirection?


The technicsl issue I have with the approaches the same one that was
raised when debated previously, ie the implementation overhead of
requiring inline schemas to be available at the top level.

Ok.  I'm ok with keeping the inline case as it is.  However, I think
we need to use the new YL-bis, so that we can support the NMDA.
Given that NMDA support is not yet fully defined, we're still in the 
transition period where support for both NMDA and non-NMDA 
implementations need to be considered.  Rob presented some options 
earlier in the thread that I think captures this.


Lou





/martin







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

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

I'm not aware of any IPR impacting either of these two drafts.

Kent // as co-author


= original message =

The authors of draft-ietf-netconf-nmda-netconf and 
draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. Please 
send your comments on this thread. Comments like “I have reviewed the documents 
and believe they are ready for publication”, or “I have concerns about the 
document because …” are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of the 
drafts.

Thanks.

Mahesh & Kent

___
Netconf mailing list
netc...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=YD0IXtUkMMI3qIK63vNpsDmumHSc_7n1T6esiz6Nzhc=5dIbx4-7CM-5NmbIyhGS16He41fyV_CoCuTLBV0mDLw=


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

Re: [netmod] schema mount and YANG library




On 1/17/2018 11:57 AM, Ladislav Lhotka wrote:

Ok.  I'm ok with keeping the inline case as it is.  However, I think

I don't agree. The metadata annotation solves real issues.

One issue with the annotation is that since the schema might be
different in different datastores, it means that the client needs to
read the annotation in all datastores, and then fetch the schemas.  So
it is a bit more difficult to work with for a client.

But it doesn't mean that the schemas*must*  be different, and it is easy to
figure out when they are the same. Also, modules sets in YLbis can further help
avoid redundant parsing of the same modules.

Lada



So I think this amplifies that the difference is one of optimization.   
Given the maturity of this work and the state of the dependent work, 
some of which is already with IESG for publication - I don't see how or 
why we should be discussing anything more than fixing flaws in this 
document.


Lou

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

Re: [netmod] schema mount and YANG library




On 1/17/2018 11:26 AM, Ladislav Lhotka wrote:

But when we discussed this the last time having inline schema
available at the top level (in the SM module), the general consensus
was that having YL under inline was the preferred approach.

What is new now is that we have an indirection; each instance has its
own pointer to the schema at the top level.  In the previous
discussion, having the schema at the top level implied that all
instances shared the same schema, and*that*  was rejected.


Indirection was possible at the previous time and is part of the current
scheme Mount definition. Yes, you need to use different mount points to
reference different schema, but take a look at the ni document that's
exactly what we are doing there. So I don't believe this is the point that

What Martin and I are talking about is a mount point that is a list node of the
"use-schema" type. There is no way how different entries of this list could have
different schemas.

The same applies to a container mount point that is inside a list. Then you can
also have multiple*instances*  of the mount point, and with "use-schema" there
is no way how these instances could have different schemas.
umm, if a server knows enough to use the right metadata indirection (per 
current proposal), it would have also know enough to use the right mount 
point and use-schema (in the old proposal).  Again, the latter is what 
we're doing to solve this *exact* problem for the non-inline case in the 
NI draft.


The only thing new in the proposal is how to encode the indirection, it 
doesn't change the fundamental points/discussion from when we decided on 
the current solution.


Lou

Lada



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

Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

2018-01-17 Thread Alexander Clemm

Hi Einar,

I suggest we add clarification that default values must be reported.  For 
on-change, clearly all changes need to be reported, whether the change is to a 
default value or not, everything else would be confusing.  Also for periodic, 
it would be confusing to leave out readings when a value is at default  versus 
not (the object might also have been deleted, etc).  So, I don’t think we need 
to add a flag or such that would allow to exclude defaults which appear to be 
of limited benefit to applications while introducing a lot more complexity to 
deal with corner cases such as the ones described.

--- Alex

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Einar Nilsen-Nygaard 
(einarnn)
Sent: Wednesday, January 17, 2018 5:27 AM
To: netmod@ietf.org
Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default 
values and RFC 6243

All,

In discussions with some customers and on implementation, the issue of defaults 
has come up. For get/get-config we have the “with defaults capability” defined 
in RFC 6243 that allows us to control the behaviour with respect to defaults. 
To remind folk with an example, we could have:


  

  http://example.com/ns/interfaces"/>


  report-all

  


The addition of the “with-defaults” tag and value determines the behavior of 
the get in this example (taken from A.3.1 in RFC 
6243).

It strikes me that we need to have a similar mechanism for telemetry, allowing 
a user to specify, for example, that for a periodic subscription on a subtree, 
they also wish default values to be reported. I think at minimum we need 
clarification on this, as section 3.7 of draft-ietf-netconf-yang-push-12 
currently says:

The content of the update record is equivalent to the contents that would be 
obtained had the same data been explicitly retrieved using e.g., a NETCONF 
"get" operation, with the same filters applied.

This text can currently only refer to a “get” as defined in RFC 6241 as there 
is no reference to RFC 6243 as yet. I think we need to address this issue now 
to define expectations, even if it is to explicitly not consider an RFC 
6243-like mechanism or to say that we only consider explicitly set values in 
telemetry, or…

Cheers,

Einar

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

Re: [netmod] schema mount and YANG library




On 1/17/2018 11:06 AM, Ladislav Lhotka wrote:

I thought that the problem with the current solution and NMDA, was that
there is no way to find out what the LNE schema is if the LNE isn't
booted, and hence isn't providing .  But I'm not sure what
issues that actually causes.  E.g. does it cause issues with
pre-configuration of the LNE?

The issue that this causes is that the schema for the pre-configured LNE
isn't
known and validity of  is unclear.

Please elaborate on what you see here as a problem.  Those working on
LNE's (including myself) don't see an issue here.

Assume the "root" mount point for LNE is inline. Can you have a pre-provisioned
configuration for a LNE entry? If so, then I assume there is no corresponding
LNE entry in . If this is correct, then I don't see from where you
get the embedded YL instance. That is,  may contain

   "ietf-logical-network-element:logical-network-element": [
 { "name": "foo",
   "root": { ... pre-provisioned config ... }
 },
 ...
   ]

But if the "foo" LNE isn't booted, then there is no "foo" entry in
, i.e. also no corresponding instance of the "root" mount point.

Is this reasoning flawed?
Yes.  At least the YL would be instantiated under operational because 
that's where it (server metadata) *always* goes.


Lou



Lada



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

[netmod] LC of NDMA NETCONF/RESTCONF drafts

2018-01-17 Thread Mahesh Jethanandani

The authors of draft-ietf-netconf-nmda-netconf and 
draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. Please 
send your comments on this thread. Comments like “I have reviewed the documents 
and believe they are ready for publication”, or “I have concerns about the 
document because …” are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of the 
drafts.

Thanks.

Mahesh & Kent

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

2018-01-17 Thread t.petch

- Original Message -
From: "Robert Wilton" 
Sent: Wednesday, January 17, 2018 10:44 AM

> Hi Tom,
>
>
> On 17/01/2018 09:52, t.petch wrote:
> > - Original Message -
> > From: "Alexander Clemm" 
> > Sent: Wednesday, January 17, 2018 2:20 AM
> >
> >> +1 to (2) as preference, followed by (1).  I don't think (3) is
needed
> > here.  The purpose is to make this human-readable and provide
readers a
> > good sense of the overall structure.
> >
> > 
> >
> > That's what I thought until Benoit said, and Robert agreed, that
> >
> > 'In the end, the tree view should be browsed with tooling.'
> The text based YANG tree diagram (i.e. covered by this draft) doesn't
> need to be browsable by tooling. The purpose of these diagrams should
> be to go in text documents to help explain and illustrate (to human
> readers) the structure of a YANG model.
>
> By "In the end, the tree view should be browsed with tooling.", what I
> mean is that I think that tools like YANG catalog will be the long
term
> way of interacting with and browsing YANG modules. For example, the
> link below for the RIP module.
>
> https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip
>
> This provides an interactive GUI "tree view" of a YANG model, which
> should be structurally equivalent as the text tree diagram, but
> otherwise the information may be represented in a more visual way.
This
> will become even more powerful when all of the standard YANG modules
are
> available together in a single browsable tree.
>
> Hopefully, that clarifies my previous comment.

Yes, thank you for the clarification,

Tom Petch





>
> Thanks,
> Rob
>
> >
> > i.e. the tree view should be machine readable after which something
is
> > produced for human consumption; not a view I share.
> >
> > Tom Petch
> >
> >
> > The authoritative specification is still the .yang itself.
Providing
> > some guidance for how to represent the tree is good but let's not
> > over-engineer this; I believe retaining some flexibility is good.
> >> --- Alex
> >>
> >>> -Original Message-
> >> ...
>  Does anyone else have an opinion on this?  I can see three
>  alternatives:
> 
>  1) allow any number of addtional spaces
>  2) allow any number of addtional spaces + define a suggested
> alignment algorithm
>  3) mandate the alignment algorithm
> >>> Definition of symbols should be precise/consistent, so that
readers
> > can
> >>> consistently interpret tree diagrams.
> >>>
> >>> I think that flexibility in layout should be OK, but the draft
> > should provide
> >>> guideline to ensure the output is readable, and likely to be
broadly
> > consistent
> >>> (since consistency aids readability).
> >>>
> >>> If the IETF data modeling group is trying to specify text output
> > precisely
> >>> enough that it can be screen scraped then we may want to consider
> > whether
> >>> we are focusing on the right solution ;-)
> >>>
> >>> In summary, (2) is my preference, followed by (1), followed by
(3).
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> 
>  /martin
> > .
> >
>

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

2018-01-17 Thread Jeff Tantsura

+1 to 2

Cheers,
Jeff

On 1/16/18, 07:41, "netmod on behalf of Martin Bjorklund" 
 wrote:

Vladimir Vassilev  wrote:
> On 01/16/2018 11:56 AM, Martin Bjorklund wrote:
> 
> > Vladimir Vassilev  wrote:

[...]

> >> There is also undocumented alignment space count function before
> >>  that pyang uses to align the  fields of child data leafs
> >> with common ancestor. If this is specified in the draft the tree
> >> output can be deterministic and for me this is an advantage. This is
> >> currently one of the few underspecified pieces of the tree format so I
> >> had to check pyang implementation in oder to generate same alignment
> >> space counts and binary identical tree output results.
> > I think that we at least should write that there may be more than one
> > space between  and :
> >
> >There may be any number of additional space characters between
> > and .
> For the sake of the argument (at least having this on the mailing list
> as reference):
> 
>should be aligned at a common offset for all sibling nodes
>   from the start of  by adding trailing spaces. The recommended
>   offset is 3 plus the length of the longest node name among all
> sibling nodes
>   including those siblings defined under choice and case nodes.
> 
> This is what pyang does now. It is not a perfect solution but it
> allows identical output down to the bit.

Does anyone else have an opinion on this?  I can see three
alternatives:

  1) allow any number of addtional spaces
  2) allow any number of addtional spaces + define a suggested
 alignment algorithm
  3) mandate the alignment algorithm


/martin

___
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

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt



> IMHO, if this module is supposed to be useful in practice, without
> requiring immediately proprietary augmentations, UDP needs to be
> supported.  RFC 5424 also states that implementations SHOULD
> support a UDP transport per RFC 5426.  

Agreed.


> Whether TCP support should be included is debatable because not a
> standard transport.  Perhaps it should not, however given that it
> has already been specified, I don't think it hurts to have it as
> a feature/option for implementations that require it.  

Given the IESG statement (copied below) and the HISTORIC downref, I
think that this would be a hard sell.  But, if it turns out that
most vendors support RFC 6587, then a case could be made for it.

Kent


> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Alex
> Campbell
> Sent: Tuesday, January 16, 2018 1:46 PM
> To: Benoit Claise ; Kent Watsen
> ; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
> 
> By the same reasoning surely UDP should not be available either, because it
> also doesn't provide security.
> 
> From: netmod  on behalf of Benoit Claise
> 
> Sent: Wednesday, 17 January 2018 6:23 a.m.
> To: Kent Watsen; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
> 
> Hi,
> >
> >** Downref: Normative reference to an Historic RFC: RFC 6587
> >
> > Kent: hmmm, what's going on here?  This YANG module is providing an
> ability to configure the "tcp" transport, even though the IESG made that
> ability historic in 2012 (see IESG Note below).  Searching online, it looks 
> like
> Cisco supports this, but Juniper does not.  What about other vendors, is it
> widely supported?  Was this discussed in the WG?  Answering my own
> question, searching my local mailbox, I don't see this ever being discussed
> before, other than Martin questioning if it was a good idea in Mar 2016 (no
> response).  Please start a thread on the list to get WG opinion if it's okay 
> for
> the draft to proceed as is or not.  Here's the IESG Note from RFC 6587:
> >
> > IESG Note
> >
> > The IESG does not recommend implementing or deploying syslog over
> > plain tcp, which is described in this document, because it lacks the
> > ability to enable strong security [RFC3365].
> >
> > Implementation of the TLS transport [RFC5425] is recommended so that
> > appropriate security features are available to operators who want to
> > deploy secure syslog.  Similarly, those security features can be
> > turned off for those who do not want them.
> >
> >
> >
> Well, I believe it's clear plain TCP should not be in the YANG module.
> 
> Regards, Benoit
> 


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

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

Hi Clyde,

One quick follow-up, it seems that all drafts are moving over to reference the
tree-diagrams draft these days. As such, I think Section 1.3 (Tree Diagram
Notation) should now be removed and Section 3.1 should change as follows:

OLD
Please see Section 1.3 for tree diagram notation.

NEW
Please see [I-D.ietf-netmod-yang-tree-diagrams] for tree diagram notation.
(yes, that should be hyperlink)

and add I-D.ietf-netmod-yang-tree-diagrams as an Informative reference.

Thanks,
Kent

= original message =

Clyde,

This draft still isn't passing idnits. I provided the link to idnits
previously, but here it is again:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tools_idnits=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo=FErz5G2HICKnT_lI6gedg7ni66XCMBrj756eh-lXdW0=.
Below is the idnits output for -19 with inlined comments.

PS: I didn't also checked the other issues we're tracking, but will when we get
past these idnits issues.

Kent

= START =
idnits 2.15.00

/tmp/draft-ietf-netmod-syslog-model-19.txt:

Checking boilerplate required by RFC 5378 and the IETF Trust (see

https://urldefense.proofpoint.com/v2/url?u=https-3A__trustee.ietf.org_license-2Dinfo=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo=X00_D6mS_CYdDDM_LABw-a_uhQziwjSvaaz8UHC6Nc0=):

No issues found here.

Checking nits according to
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_1id-2Dguidelines.txt=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo=U9PqY8kpdbwz_sL4a1DhBJagSvEx9sv9zZquldhed7U=:

No issues found here.

Checking nits according to
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_checklist=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo=K833IRzwN3sBZr2ApmQYRHjvSmKHOhNjY4JQ2mUEm18=
:

** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.

Kent: this isn't a big deal IMO, but if it's easy to fix, it saves the RFC
editor a step later on.

Miscellaneous warnings:

== Line 352 has weird spacing: '...gorithmide...'

Kent: this is fine. it is in a tree diagram.

== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?

(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).

Kent: I can't find the error. Looking at the xml, it is verbatim what I have
in the zerotouch draft. my guess is that this is a tooling error and we should
ignore it.

-- The document date (January 12, 2018) is 4 days in the past. Is this
intentional?

Kent: this is fine, it is intentional.

Checking references for intended status: Proposed Standard

(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)

== Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 1386,
but no explicit reference was found in the text

Kent: looking at the XML, I see that the entire paragraph uses '[' and ']' as
opposed to . Please fix this.

== Unused Reference: 'RFC7895' is defined on line 1456, but no explicit
reference was found in the text

Kent: looking at the XML, I see two instances of an unwanted "/" string.
For instance: / Please fix this.

** Downref: Normative reference to an Historic RFC: RFC 6587

Kent: hmmm, what's going on here? This YANG module is providing an ability to
configure the "tcp" transport, even though the IESG made that ability historic
in 2012 (see IESG Note below). Searching online, it looks like Cisco supports
this, but Juniper does not. What about other vendors, is it widely supported?
Was this discussed in the WG? Answering my own question, searching my local
mailbox, I don't see this ever being discussed before, other than Martin
questioning if it was a good idea in Mar 2016 (no response). Please start a
thread on the list to get WG opinion if it's okay for the draft to proceed as
is or not. Here's the IESG Note from RFC 6587:

IESG Note

The IESG does not recommend implementing or

Re: [netmod] schema mount and YANG library

On Wed, 2018-01-17 at 17:40 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Wed, 2018-01-17 at 17:18 +0100, Martin Bjorklund wrote:
> > > Lou Berger  wrote:
> > > > 
> > > > 
> > > > On January 17, 2018 9:42:43 AM Martin Bjorklund 
> > > > wrote:
> > > > 
> > > > > Lou Berger  wrote:
> > > > > > 
> > > > > > 
> > > > > > On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > > > > > > Lou Berger  wrote:
> > > > > > > > 
> > > > > > > > On 1/16/2018 11:15 AM, Robert Wilton wrote:
> > > > > > > > > On 16/01/2018 15:50, Martin Bjorklund wrote:
> > > > > > > > > > Lou Berger  wrote:
> > > > > > > > > > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > > > > > > > > > ... (trimming to topic)
> > > > > > > > > > > > > > > > > > > rejectected by the WG multiple times. 
> FWIW
> > > > > > > > > > > > > > > > > > > there are drafts
> > > > > > > > > > > > > > > > > > > already
> > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > No at all. The first and last time I
> proposed
> > > > > > > > > > > > > > > > > > this was on 15
> > > > > > > > > > > > > > > > > > December
> > > > > > > > > > > > > > > > > > 2017:
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod
> /cur
> > > > > > > > > > > > > > > > > > rent/msg19753.html
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Oh, I certainly would call you proposing that
> the
> > > > > > > > > > > > > > > > > schema for
> > > > > > > > > > > > > > > > > inline
> > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > part of the rest of the schema Mount module
> well
> > > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > > that. I'm
> > > > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > > I can dig up mail / slides it really
> necessary...
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I don't think this has been proposed before. 
> All
> > > > > > > > > > > > > > > > previous
> > > > > > > > > > > > > > > > proposals
> > > > > > > > > > > > > > > > were basically variants on what is now "use-
> schema", 
> > > > > > > > > > > > > > > > which works
> > > > > > > > > > > > > > > > fine
> > > > > > > > > > > > > > > > when all instances have the same schema.  This
> new
> > > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > solves
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > issue with different schemas in different
> instances.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I thought the previous proposals that as well, so
> > > > > > > > > > > > > > > don't see
> > > > > > > > > > > > > > > material
> > > > > > > > > > > > > > > difference - at least from the usage standpoint. I
> > > > > > > > > > > > > > > also don't see
> > > > > > > > > > > > > > > why
> > > > > > > > > > > > > > > the previous arguments that resulted in consensus
> for
> > > > > > > > > > > > > > > using Yang
> > > > > > > > > > > > > > > Library underneath the an in line Mount Point
> don't
> > > > > > > > > > > > > > > apply.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > B/c it doesn't work well with the NMDA.  You can't
> mount
> > > > > > > > > > > > > > yang
> > > > > > > > > > > > > > library
> > > > > > > > > > > > > > in the configuration datastores; it has to be
> mounted in
> > > > > > > > > > > > > > operational.
> > > > > > > > > > > > > > With meta-data, you can actually report the correct
> > > > > > > > > > > > > > schema even in
> > > > > > > > > > > > > > running.  (This is actually true also for pre-NMDA
> > > > > > > > > > > > > > systems).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Understood and agree there is nothing new here and the
> > > > > > > > > > > > > current
> > > > > > > > > > > > > version
> > > > > > > > > > > > > of SM (including inline) has the same limitation as
> > > > > > > > > > > > > rfc7895, and I'd
> > > > > > > > > > > > > expect it to behave the same once we have rfc7985bis
> -- in
> > > > > > > > > > > > > fact the
> > > > > > > > > > > > > inline case "just works" with YL-bis as defined today.
> > > > > > > > > > > 
> > > > > > > > > > > Martin,
> > > > > > > > > > > 
> > > > > > > > > > > you didn't respond to this point.
> > > > > > > > > > 
> > > > > > > > > > I agree, it works for non-NMDA servers. But see below.
> > > > > > > > > > 
> > > > > > > > > > > > > The argument I recall being the key point on inline
> was
> > > > > > > > > > > > > handling the
> > > > > > > > > > > > > large variety of possible different implementation
> > > > > > > > > > > > > approaches for
> > > > > > > > > > > > > modules using inline.
> > > > > > > > > > > > 
> > >

Re: [netmod] schema mount and YANG library

Ladislav Lhotka  wrote:
> On Wed, 2018-01-17 at 17:18 +0100, Martin Bjorklund wrote:
> > Lou Berger  wrote:
> > > 
> > > 
> > > On January 17, 2018 9:42:43 AM Martin Bjorklund 
> > > wrote:
> > > 
> > > > Lou Berger  wrote:
> > > > > 
> > > > > 
> > > > > On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > > > > > Lou Berger  wrote:
> > > > > > > 
> > > > > > > On 1/16/2018 11:15 AM, Robert Wilton wrote:
> > > > > > > > On 16/01/2018 15:50, Martin Bjorklund wrote:
> > > > > > > > > Lou Berger  wrote:
> > > > > > > > > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > > > > > > > > ... (trimming to topic)
> > > > > > > > > > > > > > > > > > rejectected by the WG multiple times.  FWIW
> > > > > > > > > > > > > > > > > > there are drafts
> > > > > > > > > > > > > > > > > > already
> > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > No at all. The first and last time I proposed
> > > > > > > > > > > > > > > > > this was on 15
> > > > > > > > > > > > > > > > > December
> > > > > > > > > > > > > > > > > 2017:
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod/cur
> > > > > > > > > > > > > > > > > rent/msg19753.html
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Oh, I certainly would call you proposing that 
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > schema for
> > > > > > > > > > > > > > > > inline
> > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > part of the rest of the schema Mount module well
> > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > that. I'm
> > > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > I can dig up mail / slides it really 
> > > > > > > > > > > > > > > > necessary...
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I don't think this has been proposed before.  All
> > > > > > > > > > > > > > > previous
> > > > > > > > > > > > > > > proposals
> > > > > > > > > > > > > > > were basically variants on what is now 
> > > > > > > > > > > > > > > "use-schema", 
> > > > > > > > > > > > > > > which works
> > > > > > > > > > > > > > > fine
> > > > > > > > > > > > > > > when all instances have the same schema.  This new
> > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > solves
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > issue with different schemas in different 
> > > > > > > > > > > > > > > instances.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I thought the previous proposals that as well, so
> > > > > > > > > > > > > > don't see
> > > > > > > > > > > > > > material
> > > > > > > > > > > > > > difference - at least from the usage standpoint. I
> > > > > > > > > > > > > > also don't see
> > > > > > > > > > > > > > why
> > > > > > > > > > > > > > the previous arguments that resulted in consensus 
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > using Yang
> > > > > > > > > > > > > > Library underneath the an in line Mount Point don't
> > > > > > > > > > > > > > apply.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > B/c it doesn't work well with the NMDA.  You can't 
> > > > > > > > > > > > > mount
> > > > > > > > > > > > > yang
> > > > > > > > > > > > > library
> > > > > > > > > > > > > in the configuration datastores; it has to be mounted 
> > > > > > > > > > > > > in
> > > > > > > > > > > > > operational.
> > > > > > > > > > > > > With meta-data, you can actually report the correct
> > > > > > > > > > > > > schema even in
> > > > > > > > > > > > > running.  (This is actually true also for pre-NMDA
> > > > > > > > > > > > > systems).
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Understood and agree there is nothing new here and the
> > > > > > > > > > > > current
> > > > > > > > > > > > version
> > > > > > > > > > > > of SM (including inline) has the same limitation as
> > > > > > > > > > > > rfc7895, and I'd
> > > > > > > > > > > > expect it to behave the same once we have rfc7985bis -- 
> > > > > > > > > > > > in
> > > > > > > > > > > > fact the
> > > > > > > > > > > > inline case "just works" with YL-bis as defined today.
> > > > > > > > > > 
> > > > > > > > > > Martin,
> > > > > > > > > > 
> > > > > > > > > > you didn't respond to this point.
> > > > > > > > > 
> > > > > > > > > I agree, it works for non-NMDA servers. But see below.
> > > > > > > > > 
> > > > > > > > > > > > The argument I recall being the key point on inline was
> > > > > > > > > > > > handling the
> > > > > > > > > > > > large variety of possible different implementation
> > > > > > > > > > > > approaches for
> > > > > > > > > > > > modules using inline.
> > > > > > > > > > > 
> > > > > > > > > > > I think these still are covered.
> > >

Re: [netmod] schema mount and YANG library

On Wed, 2018-01-17 at 17:18 +0100, Martin Bjorklund wrote:
> Lou Berger  wrote:
> > 
> > 
> > On January 17, 2018 9:42:43 AM Martin Bjorklund 
> > wrote:
> > 
> > > Lou Berger  wrote:
> > > > 
> > > > 
> > > > On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > > > > Lou Berger  wrote:
> > > > > > 
> > > > > > On 1/16/2018 11:15 AM, Robert Wilton wrote:
> > > > > > > On 16/01/2018 15:50, Martin Bjorklund wrote:
> > > > > > > > Lou Berger  wrote:
> > > > > > > > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > > > > > > > ... (trimming to topic)
> > > > > > > > > > > > > > > > > rejectected by the WG multiple times.  FWIW
> > > > > > > > > > > > > > > > > there are drafts
> > > > > > > > > > > > > > > > > already
> > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > No at all. The first and last time I proposed
> > > > > > > > > > > > > > > > this was on 15
> > > > > > > > > > > > > > > > December
> > > > > > > > > > > > > > > > 2017:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod/cur
> > > > > > > > > > > > > > > > rent/msg19753.html
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Oh, I certainly would call you proposing that the
> > > > > > > > > > > > > > > schema for
> > > > > > > > > > > > > > > inline
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > part of the rest of the schema Mount module well
> > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > that. I'm
> > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > I can dig up mail / slides it really necessary...
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I don't think this has been proposed before.  All
> > > > > > > > > > > > > > previous
> > > > > > > > > > > > > > proposals
> > > > > > > > > > > > > > were basically variants on what is now 
> > > > > > > > > > > > > > "use-schema", 
> > > > > > > > > > > > > > which works
> > > > > > > > > > > > > > fine
> > > > > > > > > > > > > > when all instances have the same schema.  This new
> > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > solves
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > issue with different schemas in different instances.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I thought the previous proposals that as well, so
> > > > > > > > > > > > > don't see
> > > > > > > > > > > > > material
> > > > > > > > > > > > > difference - at least from the usage standpoint. I
> > > > > > > > > > > > > also don't see
> > > > > > > > > > > > > why
> > > > > > > > > > > > > the previous arguments that resulted in consensus for
> > > > > > > > > > > > > using Yang
> > > > > > > > > > > > > Library underneath the an in line Mount Point don't
> > > > > > > > > > > > > apply.
> > > > > > > > > > > > 
> > > > > > > > > > > > B/c it doesn't work well with the NMDA.  You can't mount
> > > > > > > > > > > > yang
> > > > > > > > > > > > library
> > > > > > > > > > > > in the configuration datastores; it has to be mounted in
> > > > > > > > > > > > operational.
> > > > > > > > > > > > With meta-data, you can actually report the correct
> > > > > > > > > > > > schema even in
> > > > > > > > > > > > running.  (This is actually true also for pre-NMDA
> > > > > > > > > > > > systems).
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Understood and agree there is nothing new here and the
> > > > > > > > > > > current
> > > > > > > > > > > version
> > > > > > > > > > > of SM (including inline) has the same limitation as
> > > > > > > > > > > rfc7895, and I'd
> > > > > > > > > > > expect it to behave the same once we have rfc7985bis -- in
> > > > > > > > > > > fact the
> > > > > > > > > > > inline case "just works" with YL-bis as defined today.
> > > > > > > > > 
> > > > > > > > > Martin,
> > > > > > > > > 
> > > > > > > > > you didn't respond to this point.
> > > > > > > > 
> > > > > > > > I agree, it works for non-NMDA servers. But see below.
> > > > > > > > 
> > > > > > > > > > > The argument I recall being the key point on inline was
> > > > > > > > > > > handling the
> > > > > > > > > > > large variety of possible different implementation
> > > > > > > > > > > approaches for
> > > > > > > > > > > modules using inline.
> > > > > > > > > > 
> > > > > > > > > > I think these still are covered.
> > > > > > > > > > 
> > > > > > > > > > > For example an LNE that is implemented using
> > > > > > > > > > > VMs which can be managed by the host at different times of
> > > > > > > > > > > the VMs
> > > > > > > > > > > operational life cycle based on customer/provider
> > > > > > > > > > > requirements.  I
> > > > > > > > > > > really don't see how YL-bis has any bearing on this point
> > > > > > > > > > > and
> > > > > > > > > > 
> > > > > >

Re: [netmod] schema mount and YANG library

On Wed, 2018-01-17 at 10:43 -0500, Lou Berger wrote:
> 
> On January 17, 2018 9:42:43 AM Martin Bjorklund  wrote:
> 
> > Lou Berger  wrote:
> > > 
> > > 
> > > On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > > > Lou Berger  wrote:
> > > > > 
> > > > > On 1/16/2018 11:15 AM, Robert Wilton wrote:
> > > > > > On 16/01/2018 15:50, Martin Bjorklund wrote:
> > > > > > > Lou Berger  wrote:
> > > > > > > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > > > > > > ... (trimming to topic)
> > > > > > > > > > > > > > > > rejectected by the WG multiple times.  FWIW
> > > > > > > > > > > > > > > > there are drafts
> > > > > > > > > > > > > > > > already
> > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > No at all. The first and last time I proposed this
> > > > > > > > > > > > > > > was on 15
> > > > > > > > > > > > > > > December
> > > > > > > > > > > > > > > 2017:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod/curre
> > > > > > > > > > > > > > > nt/msg19753.html
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Oh, I certainly would call you proposing that the
> > > > > > > > > > > > > > schema for inline
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > part of the rest of the schema Mount module well
> > > > > > > > > > > > > > before that. I'm
> > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > I can dig up mail / slides it really necessary...
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I don't think this has been proposed before.  All
> > > > > > > > > > > > > previous proposals
> > > > > > > > > > > > > were basically variants on what is now "use-schema",
> > > > > > > > > > > > > which works
> > > > > > > > > > > > > fine
> > > > > > > > > > > > > when all instances have the same schema.  This new
> > > > > > > > > > > > > proposal solves
> > > > > > > > > > > > > the
> > > > > > > > > > > > > issue with different schemas in different instances.
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > I thought the previous proposals that as well, so don't
> > > > > > > > > > > > see material
> > > > > > > > > > > > difference - at least from the usage standpoint. I also
> > > > > > > > > > > > don't see why
> > > > > > > > > > > > the previous arguments that resulted in consensus for
> > > > > > > > > > > > using Yang
> > > > > > > > > > > > Library underneath the an in line Mount Point don't
> > > > > > > > > > > > apply.
> > > > > > > > > > > 
> > > > > > > > > > > B/c it doesn't work well with the NMDA.  You can't mount
> > > > > > > > > > > yang library
> > > > > > > > > > > in the configuration datastores; it has to be mounted in
> > > > > > > > > > > operational.
> > > > > > > > > > > With meta-data, you can actually report the correct schema
> > > > > > > > > > > even in
> > > > > > > > > > > running.  (This is actually true also for pre-NMDA
> > > > > > > > > > > systems).
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Understood and agree there is nothing new here and the
> > > > > > > > > > current version
> > > > > > > > > > of SM (including inline) has the same limitation as rfc7895,
> > > > > > > > > > and I'd
> > > > > > > > > > expect it to behave the same once we have rfc7985bis -- in
> > > > > > > > > > fact the
> > > > > > > > > > inline case "just works" with YL-bis as defined today.
> > > > > > > > 
> > > > > > > > Martin,
> > > > > > > > 
> > > > > > > > you didn't respond to this point.
> > > > > > > 
> > > > > > > I agree, it works for non-NMDA servers. But see below.
> > > > > > > 
> > > > > > > > > > The argument I recall being the key point on inline was
> > > > > > > > > > handling the
> > > > > > > > > > large variety of possible different implementation
> > > > > > > > > > approaches for
> > > > > > > > > > modules using inline.
> > > > > > > > > 
> > > > > > > > > I think these still are covered.
> > > > > > > > > 
> > > > > > > > > > For example an LNE that is implemented using
> > > > > > > > > > VMs which can be managed by the host at different times of
> > > > > > > > > > the VMs
> > > > > > > > > > operational life cycle based on customer/provider
> > > > > > > > > > requirements.  I
> > > > > > > > > > really don't see how YL-bis has any bearing on this point
> > > > > > > > > > and
> > > > > > > > > 
> > > > > > > > > Using the new proposed meta data annotation together with the
> > > > > > > > > new YL
> > > > > > > > > means that SM can support the use case above also in an NMDA
> > > > > > > > > server.
> > > > > > > > > I think the new proposed solution covers more use cases than
> > > > > > > > > the
> > > > > > > > > previous solution.
> > > > > > > > 
> > > > > > > > how so?  The inline mount point would contain YL-bis and have
> > > > > > > > the same
> > > > > > > > information there,

Re: [netmod] schema mount and YANG library

Lou Berger  wrote:
> 
> 
> On January 17, 2018 9:42:43 AM Martin Bjorklund 
> wrote:
> 
> > Lou Berger  wrote:
> >>
> >>
> >> On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> >> > Lou Berger  wrote:
> >> >>
> >> >> On 1/16/2018 11:15 AM, Robert Wilton wrote:
> >> >>> On 16/01/2018 15:50, Martin Bjorklund wrote:
> >>  Lou Berger  wrote:
> >> > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> >> > ... (trimming to topic)
> >> > rejectected by the WG multiple times.  FWIW there are drafts
> >> > already
> >> > with
> >>  No at all. The first and last time I proposed this was on 15
> >>  December
> >>  2017:
> >> 
> >>  https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
> >> 
> >> >>> Oh, I certainly would call you proposing that the schema for
> >> >>> inline
> >> >>> be
> >> >>> part of the rest of the schema Mount module well before
> >> >>> that. I'm
> >> >>> sure
> >> >>> I can dig up mail / slides it really necessary...
> >> >> I don't think this has been proposed before.  All previous
> >> >> proposals
> >> >> were basically variants on what is now "use-schema", which works
> >> >> fine
> >> >> when all instances have the same schema.  This new proposal
> >> >> solves
> >> >> the
> >> >> issue with different schemas in different instances.
> >> >>
> >> > I thought the previous proposals that as well, so don't see
> >> > material
> >> > difference - at least from the usage standpoint. I also don't see
> >> > why
> >> > the previous arguments that resulted in consensus for using Yang
> >> > Library underneath the an in line Mount Point don't apply.
> >>  B/c it doesn't work well with the NMDA.  You can't mount yang
> >>  library
> >>  in the configuration datastores; it has to be mounted in
> >>  operational.
> >>  With meta-data, you can actually report the correct schema even in
> >>  running.  (This is actually true also for pre-NMDA systems).
> >> 
> >> >>> Understood and agree there is nothing new here and the current
> >> >>> version
> >> >>> of SM (including inline) has the same limitation as rfc7895, and 
> >> >>> I'd
> >> >>> expect it to behave the same once we have rfc7985bis -- in fact the
> >> >>> inline case "just works" with YL-bis as defined today.
> >> > Martin,
> >> >
> >> > you didn't respond to this point.
> >>  I agree, it works for non-NMDA servers. But see below.
> >> 
> >> >>> The argument I recall being the key point on inline was handling 
> >> >>> the
> >> >>> large variety of possible different implementation approaches for
> >> >>> modules using inline.
> >> >> I think these still are covered.
> >> >>
> >> >>> For example an LNE that is implemented using
> >> >>> VMs which can be managed by the host at different times of the VMs
> >> >>> operational life cycle based on customer/provider requirements.  I
> >> >>> really don't see how YL-bis has any bearing on this point and
> >> >> Using the new proposed meta data annotation together with the new YL
> >> >> means that SM can support the use case above also in an NMDA server.
> >> >> I think the new proposed solution covers more use cases than the
> >> >> previous solution.
> >> > how so?  The inline mount point would contain YL-bis and have the 
> >> > same
> >> > information there, just scoped for the mount point.  It's true a
> >> > client would need to understand the mount point's schema only upon
> >> > parsing the YL under the mount point and this schema could not be
> >> > shared across inline mount points.  But this is as was discussed in
> >> > the past and unchanged from YL.
> >> >
> >> >> Do you think that there is any use case that the proposed solution
> >> >> cannot handle, but the previous solution did?
> >> > yes.  with VM/container technologies the YL / schema can change under
> >> > the mount point from time to time during normal operation (i.e.,
> >> > during runtime, no reboot) and, in some implementations, may require
> >> > some level of rpc operation to access even the schema.  The new (and
> >> > previously proposed approach) of having inline schema available from
> >> > the top level greatly complicates these cases.  Also keep in mind 
> >> > that
> >> > there will be cases where the ability to access information under an
> >> > inline mount point will dynamically change in operation (and top 
> >> > level
> >> > YL would need to remove schema information for the inline mount

Re: [netmod] schema mount and YANG library

On Wed, 2018-01-17 at 09:09 -0500, Lou Berger wrote:
> 
> On 1/17/2018 1:59 AM, Ladislav Lhotka wrote:
> ...
> > > > > > > I think
> > > > > > > it is incumbent upon those revisiting past/closed WG decisions (in
> > > > > > > this case, inline schema being represented by YL) to argue why the
> > > > > > > decision needs to be revisited.
> > > > > > 
> > > > > > I'm repeating my self: b/c the current solution doesn't work well
> > > > > > with
> > > > > > the NMDA.
> > > > > 
> > > > > I simply don't understand how YL-bis works at the root node but
> > > > > doesn't work equally at an inline mount point.  Can you elaborate?
> > > > 
> > > > With NMDA, a server may have one schema for the config datastore and
> > > > another one for operational (one is a superset of the other).  A
> > > > mounted YL can only be present in operational.  Thus, there's no way a
> > > > client can learn the schema for config.
> > > 
> > > If the LNE mounted the full YL-bis at the mount point then you would
> > > have the list of datastores, and the schema associated with each
> > > datastore.  Of course, this would only be available in operational, but
> > > that is the same as a regular server support YL-bis.
> > 
> > YL-bis is different in that it is in fact metadata even though we call it
> > state
> > data.
> 
> I couldn't agree more.  YL and SM are server metadata and are 
> independent of any DS.  They could be accessed via any (as others have 
> suggested), but we are currently choosing to access if via operational 
> state.  With NMDA, I think personally think server meta data should have 
> it's own DS.  This discussion has convinced me that the current proposed 
> alternative, of accessing as operational data is flawed and even access 
> via *any* DS is preferable.

Yes, I would support an extra datastore.

> 
> > In any case, no matter what datastores the server has, YL-bis is the
> > single well-known location from which the schema of all datastores can be
> > retrieved.
> 
> That's a nice idea, but as was discussed in december, the direction 
> being taken doesn't include SM so this statement isn't *currently* true.

I assume SM is also part of metadata, so it would be in the same datastore as
YL.

> 
> > 
> > We could refer to  as the place from which the mounted schemas
> > of
> > NMDA-standard config datastores can be retrieved (except for special cases,
> > one
> > is discussed below). But if there is another config datastore (e.g. dynamic)
> > with an inline mount point instance, it is unclear where to look for the
> > mounted
> > schema.
> 
> Why?  Is it unclear where to look for YL-bis in this case?  Why is SM 
> any different than YL?

NMDA requires that standard config data be also in , so if we have
a mount point instance in , there is (mostly) a corresponding instance
in , which is the place where the embedded YL can be found. I don't
think other non-standard datastores necessarily have this relationship with
.

> 
> >   With my proposal, the mount point instance will be annotated with
> > @schema-ref that points to a schema in the top-level YL.
> 
> right and as we thrashed out the last time we had discussed this with 
> the whole WG, having inline schema available at the top level was not 
> the preferred solution.

Because we didn't have the metadata annotation that can now refer from any
inline mount point instance to a schema that is placed at the top level. It is
just a simple indirection.

> 
> > 
> > > I thought that the problem with the current solution and NMDA, was that
> > > there is no way to find out what the LNE schema is if the LNE isn't
> > > booted, and hence isn't providing .  But I'm not sure what
> > > issues that actually causes.  E.g. does it cause issues with
> > > pre-configuration of the LNE?
> > 
> > The issue that this causes is that the schema for the pre-configured LNE
> > isn't
> > known and validity of  is unclear.
> 
> Please elaborate on what you see here as a problem.  Those working on 
> LNE's (including myself) don't see an issue here.

Assume the "root" mount point for LNE is inline. Can you have a pre-provisioned
configuration for a LNE entry? If so, then I assume there is no corresponding
LNE entry in . If this is correct, then I don't see from where you
get the embedded YL instance. That is,  may contain

  "ietf-logical-network-element:logical-network-element": [
{ "name": "foo",
  "root": { ... pre-provisioned config ... }
},
...
  ]

But if the "foo" LNE isn't booted, then there is no "foo" entry in
, i.e. also no corresponding instance of the "root" mount point.

Is this reasoning flawed?

Lada

> 
> Lou
> > 
> > Lada
> > 
> 
> 
-- 
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] schema mount and YANG library




On January 17, 2018 9:42:43 AM Martin Bjorklund  wrote:


Lou Berger  wrote:



On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>>
>> On 1/16/2018 11:15 AM, Robert Wilton wrote:
>>> On 16/01/2018 15:50, Martin Bjorklund wrote:
 Lou Berger  wrote:
> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> ... (trimming to topic)
> rejectected by the WG multiple times.  FWIW there are drafts
> already
> with
 No at all. The first and last time I proposed this was on 15
 December
 2017:

 https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html

>>> Oh, I certainly would call you proposing that the schema for inline
>>> be
>>> part of the rest of the schema Mount module well before that. I'm
>>> sure
>>> I can dig up mail / slides it really necessary...
>> I don't think this has been proposed before.  All previous proposals
>> were basically variants on what is now "use-schema", which works
>> fine
>> when all instances have the same schema.  This new proposal solves
>> the
>> issue with different schemas in different instances.
>>
> I thought the previous proposals that as well, so don't see material
> difference - at least from the usage standpoint. I also don't see why
> the previous arguments that resulted in consensus for using Yang
> Library underneath the an in line Mount Point don't apply.
 B/c it doesn't work well with the NMDA.  You can't mount yang library
 in the configuration datastores; it has to be mounted in operational.
 With meta-data, you can actually report the correct schema even in
 running.  (This is actually true also for pre-NMDA systems).

>>> Understood and agree there is nothing new here and the current version
>>> of SM (including inline) has the same limitation as rfc7895, and I'd
>>> expect it to behave the same once we have rfc7985bis -- in fact the
>>> inline case "just works" with YL-bis as defined today.
> Martin,
>
> you didn't respond to this point.
 I agree, it works for non-NMDA servers. But see below.

>>> The argument I recall being the key point on inline was handling the
>>> large variety of possible different implementation approaches for
>>> modules using inline.
>> I think these still are covered.
>>
>>> For example an LNE that is implemented using
>>> VMs which can be managed by the host at different times of the VMs
>>> operational life cycle based on customer/provider requirements.  I
>>> really don't see how YL-bis has any bearing on this point and
>> Using the new proposed meta data annotation together with the new YL
>> means that SM can support the use case above also in an NMDA server.
>> I think the new proposed solution covers more use cases than the
>> previous solution.
> how so?  The inline mount point would contain YL-bis and have the same
> information there, just scoped for the mount point.  It's true a
> client would need to understand the mount point's schema only upon
> parsing the YL under the mount point and this schema could not be
> shared across inline mount points.  But this is as was discussed in
> the past and unchanged from YL.
>
>> Do you think that there is any use case that the proposed solution
>> cannot handle, but the previous solution did?
> yes.  with VM/container technologies the YL / schema can change under
> the mount point from time to time during normal operation (i.e.,
> during runtime, no reboot) and, in some implementations, may require
> some level of rpc operation to access even the schema.  The new (and
> previously proposed approach) of having inline schema available from
> the top level greatly complicates these cases.  Also keep in mind that
> there will be cases where the ability to access information under an
> inline mount point will dynamically change in operation (and top level
> YL would need to remove schema information for the inline mount
> point.)  As before, from the usage standpoint, these changes don't
> provide a whole lot of value and seem to optimizing for something not
> needed in the inline case.
 I think this is an implementation issue, rather than a problem with
 the proposed mechanism, and it is present in the current solution as
 well.  An implementation that can handle dynamically changing mounted
 YLs in the current solution can do that in the new solution as well.

>>> I think
>>> it is incumbent upon those revisiting past/closed WG decisions (in
>>> this case, inline schema being represented by YL) to argue why

Re: [netmod] schema mount and YANG library

Lou Berger  wrote:
> 
> 
> On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > Lou Berger  wrote:
> >>
> >> On 1/16/2018 11:15 AM, Robert Wilton wrote:
> >>> On 16/01/2018 15:50, Martin Bjorklund wrote:
>  Lou Berger  wrote:
> > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > ... (trimming to topic)
> > rejectected by the WG multiple times.  FWIW there are drafts
> > already
> > with
>  No at all. The first and last time I proposed this was on 15
>  December
>  2017:
> 
>  https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
> 
> >>> Oh, I certainly would call you proposing that the schema for 
> >>> inline
> >>> be
> >>> part of the rest of the schema Mount module well before that. I'm
> >>> sure
> >>> I can dig up mail / slides it really necessary...
> >> I don't think this has been proposed before.  All previous 
> >> proposals
> >> were basically variants on what is now "use-schema", which works
> >> fine
> >> when all instances have the same schema.  This new proposal solves
> >> the
> >> issue with different schemas in different instances.
> >>
> > I thought the previous proposals that as well, so don't see material
> > difference - at least from the usage standpoint. I also don't see 
> > why
> > the previous arguments that resulted in consensus for using Yang
> > Library underneath the an in line Mount Point don't apply.
>  B/c it doesn't work well with the NMDA.  You can't mount yang library
>  in the configuration datastores; it has to be mounted in operational.
>  With meta-data, you can actually report the correct schema even in
>  running.  (This is actually true also for pre-NMDA systems).
> 
> >>> Understood and agree there is nothing new here and the current version
> >>> of SM (including inline) has the same limitation as rfc7895, and I'd
> >>> expect it to behave the same once we have rfc7985bis -- in fact the
> >>> inline case "just works" with YL-bis as defined today.
> > Martin,
> >
> > you didn't respond to this point.
>  I agree, it works for non-NMDA servers. But see below.
> 
> >>> The argument I recall being the key point on inline was handling the
> >>> large variety of possible different implementation approaches for
> >>> modules using inline.
> >> I think these still are covered.
> >>
> >>> For example an LNE that is implemented using
> >>> VMs which can be managed by the host at different times of the VMs
> >>> operational life cycle based on customer/provider requirements.  I
> >>> really don't see how YL-bis has any bearing on this point and
> >> Using the new proposed meta data annotation together with the new YL
> >> means that SM can support the use case above also in an NMDA server.
> >> I think the new proposed solution covers more use cases than the
> >> previous solution.
> > how so?  The inline mount point would contain YL-bis and have the same
> > information there, just scoped for the mount point.  It's true a
> > client would need to understand the mount point's schema only upon
> > parsing the YL under the mount point and this schema could not be
> > shared across inline mount points.  But this is as was discussed in
> > the past and unchanged from YL.
> >
> >> Do you think that there is any use case that the proposed solution
> >> cannot handle, but the previous solution did?
> > yes.  with VM/container technologies the YL / schema can change under
> > the mount point from time to time during normal operation (i.e.,
> > during runtime, no reboot) and, in some implementations, may require
> > some level of rpc operation to access even the schema.  The new (and
> > previously proposed approach) of having inline schema available from
> > the top level greatly complicates these cases.  Also keep in mind that
> > there will be cases where the ability to access information under an
> > inline mount point will dynamically change in operation (and top level
> > YL would need to remove schema information for the inline mount
> > point.)  As before, from the usage standpoint, these changes don't
> > provide a whole lot of value and seem to optimizing for something not
> > needed in the inline case.
>  I think this is an implementation issue, rather than a problem with
>  the proposed mechanism, and it is present in the current solution as
>  well.  An implementation that can handle dynamically changing mounted
>  YLs in the current solution can do that in the new solution as well.
> 
> >>> I think
>

Re: [netmod] schema mount and YANG library




On 1/17/2018 3:20 AM, Martin Bjorklund wrote:

Lou Berger  wrote:


On 1/16/2018 11:15 AM, Robert Wilton wrote:

On 16/01/2018 15:50, Martin Bjorklund wrote:

Lou Berger  wrote:

On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
... (trimming to topic)

rejectected by the WG multiple times.  FWIW there are drafts
already
with

No at all. The first and last time I proposed this was on 15
December
2017:

https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html


Oh, I certainly would call you proposing that the schema for inline
be
part of the rest of the schema Mount module well before that. I'm
sure
I can dig up mail / slides it really necessary...

I don't think this has been proposed before.  All previous proposals
were basically variants on what is now "use-schema", which works fine
when all instances have the same schema.  This new proposal solves the
issue with different schemas in different instances.


I thought the previous proposals that as well, so don't see material
difference - at least from the usage standpoint. I also don't see why
the previous arguments that resulted in consensus for using Yang
Library underneath the an in line Mount Point don't apply.

B/c it doesn't work well with the NMDA.  You can't mount yang library
in the configuration datastores; it has to be mounted in operational.
With meta-data, you can actually report the correct schema even in
running.  (This is actually true also for pre-NMDA systems).


Understood and agree there is nothing new here and the current version
of SM (including inline) has the same limitation as rfc7895, and I'd
expect it to behave the same once we have rfc7985bis -- in fact the
inline case "just works" with YL-bis as defined today.

Martin,

you didn't respond to this point.

I agree, it works for non-NMDA servers. But see below.


The argument I recall being the key point on inline was handling the
large variety of possible different implementation approaches for
modules using inline.

I think these still are covered.


For example an LNE that is implemented using
VMs which can be managed by the host at different times of the VMs
operational life cycle based on customer/provider requirements.  I
really don't see how YL-bis has any bearing on this point and

Using the new proposed meta data annotation together with the new YL
means that SM can support the use case above also in an NMDA server.
I think the new proposed solution covers more use cases than the
previous solution.

how so?  The inline mount point would contain YL-bis and have the same
information there, just scoped for the mount point.  It's true a
client would need to understand the mount point's schema only upon
parsing the YL under the mount point and this schema could not be
shared across inline mount points.  But this is as was discussed in
the past and unchanged from YL.


Do you think that there is any use case that the proposed solution
cannot handle, but the previous solution did?

yes.  with VM/container technologies the YL / schema can change under
the mount point from time to time during normal operation (i.e.,
during runtime, no reboot) and, in some implementations, may require
some level of rpc operation to access even the schema.  The new (and
previously proposed approach) of having inline schema available from
the top level greatly complicates these cases.  Also keep in mind that
there will be cases where the ability to access information under an
inline mount point will dynamically change in operation (and top level
YL would need to remove schema information for the inline mount
point.)  As before, from the usage standpoint, these changes don't
provide a whole lot of value and seem to optimizing for something not
needed in the inline case.

I think this is an implementation issue, rather than a problem with
the proposed mechanism, and it is present in the current solution as
well.  An implementation that can handle dynamically changing mounted
YLs in the current solution can do that in the new solution as well.


I think
it is incumbent upon those revisiting past/closed WG decisions (in
this case, inline schema being represented by YL) to argue why the
decision needs to be revisited.

I'm repeating my self: b/c the current solution doesn't work well with
the NMDA.

I simply don't understand how YL-bis works at the root node but
doesn't work equally at an inline mount point.  Can you elaborate?

With NMDA, a server may have one schema for the config datastore and
another one for operational (one is a superset of the other).  A
mounted YL can only be present in operational.  Thus, there's no way a
client can learn the schema for config.

If the LNE mounted the full YL-bis at the mount point then you would
have the list of datastores, and the schema associated with each
datastore.  Of course, this would only be available in operational,
but
that is the same as a regular server support YL-bis.

exactly my point.

Yes, you're

Re: [netmod] schema mount and YANG library




On 1/17/2018 1:59 AM, Ladislav Lhotka wrote:
...

I think
it is incumbent upon those revisiting past/closed WG decisions (in
this case, inline schema being represented by YL) to argue why the
decision needs to be revisited.

I'm repeating my self: b/c the current solution doesn't work well with
the NMDA.

I simply don't understand how YL-bis works at the root node but
doesn't work equally at an inline mount point.  Can you elaborate?

With NMDA, a server may have one schema for the config datastore and
another one for operational (one is a superset of the other).  A
mounted YL can only be present in operational.  Thus, there's no way a
client can learn the schema for config.

If the LNE mounted the full YL-bis at the mount point then you would
have the list of datastores, and the schema associated with each
datastore.  Of course, this would only be available in operational, but
that is the same as a regular server support YL-bis.

YL-bis is different in that it is in fact metadata even though we call it state
data.
I couldn't agree more.  YL and SM are server metadata and are 
independent of any DS.  They could be accessed via any (as others have 
suggested), but we are currently choosing to access if via operational 
state.  With NMDA, I think personally think server meta data should have 
it's own DS.  This discussion has convinced me that the current proposed 
alternative, of accessing as operational data is flawed and even access 
via *any* DS is preferable.



In any case, no matter what datastores the server has, YL-bis is the
single well-known location from which the schema of all datastores can be
retrieved.
That's a nice idea, but as was discussed in december, the direction 
being taken doesn't include SM so this statement isn't *currently* true.




We could refer to  as the place from which the mounted schemas of
NMDA-standard config datastores can be retrieved (except for special cases, one
is discussed below). But if there is another config datastore (e.g. dynamic)
with an inline mount point instance, it is unclear where to look for the mounted
schema.
Why?  Is it unclear where to look for YL-bis in this case?  Why is SM 
any different than YL?



  With my proposal, the mount point instance will be annotated with
@schema-ref that points to a schema in the top-level YL.
right and as we thrashed out the last time we had discussed this with 
the whole WG, having inline schema available at the top level was not 
the preferred solution.





I thought that the problem with the current solution and NMDA, was that
there is no way to find out what the LNE schema is if the LNE isn't
booted, and hence isn't providing .  But I'm not sure what
issues that actually causes.  E.g. does it cause issues with
pre-configuration of the LNE?

The issue that this causes is that the schema for the pre-configured LNE isn't
known and validity of  is unclear.
Please elaborate on what you see here as a problem.  Those working on 
LNE's (including myself) don't see an issue here.


Lou


Lada



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

[netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

2018-01-17 Thread Einar Nilsen-Nygaard (einarnn)

All,

In discussions with some customers and on implementation, the issue of defaults 
has come up. For get/get-config we have the “with defaults capability” defined 
in RFC 6243 that allows us to control the behaviour with respect to defaults. 
To remind folk with an example, we could have:


  

  http://example.com/ns/interfaces"/>


  report-all

  


The addition of the “with-defaults” tag and value determines the behavior of 
the get in this example (taken from A.3.1 in RFC 
6243).

It strikes me that we need to have a similar mechanism for telemetry, allowing 
a user to specify, for example, that for a periodic subscription on a subtree, 
they also wish default values to be reported. I think at minimum we need 
clarification on this, as section 3.7 of draft-ietf-netconf-yang-push-12 
currently says:

The content of the update record is equivalent to the contents that would be 
obtained had the same data been explicitly retrieved using e.g., a NETCONF 
"get" operation, with the same filters applied.

This text can currently only refer to a “get” as defined in RFC 6241 as there 
is no reference to RFC 6243 as yet. I think we need to address this issue now 
to define expectations, even if it is to explicitly not consider an RFC 
6243-like mechanism or to say that we only consider explicitly set values in 
telemetry, or…

Cheers,

Einar

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

2018-01-17 Thread Benoit Claise


Hi Tom,

Hi Tom,


On 17/01/2018 09:52, t.petch wrote:

- Original Message -
From: "Alexander Clemm" 
Sent: Wednesday, January 17, 2018 2:20 AM


+1 to (2) as preference, followed by (1).  I don't think (3) is needed

here.  The purpose is to make this human-readable and provide readers a
good sense of the overall structure.



That's what I thought until Benoit said, and Robert agreed, that

'In the end, the tree view should be browsed with tooling.'
The text based YANG tree diagram (i.e. covered by this draft) doesn't 
need to be browsable by tooling.  The purpose of these diagrams should 
be to go in text documents to help explain and illustrate (to human 
readers) the structure of a YANG model.


By "In the end, the tree view should be browsed with tooling.", what I 
mean is that I think that tools like YANG catalog will be the long 
term way of interacting with and browsing YANG modules. For example, 
the link below for the RIP module.


https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip

This provides an interactive GUI "tree view" of a YANG model, which 
should be structurally equivalent as the text tree diagram, but 
otherwise the information may be represented in a more visual way. 
This will become even more powerful when all of the standard YANG 
modules are available together in a single browsable tree.



Exactly what I meant.
'In the end, the tree view should be browsed with tooling.' doesn't mean 
that the tree diagram, to be inserted in the RFC text,(according to 
draft-ietf-netmod-yang-tree-diagrams-04 
should 
be browsed with tooling.


Sorry if it was not clear.

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

On Wed, Jan 17, 2018 at 09:52:27AM -, t.petch wrote:
> 
> That's what I thought until Benoit said, and Robert agreed, that
> 
> 'In the end, the tree view should be browsed with tooling.'
> 
> i.e. the tree view should be machine readable after which something is
> produced for human consumption; not a view I share.
>

I think they did not say that the tooling should rely on tree views
published in RFCs as input. We should discourage tools to read tree
rendings as input; tools should read YANG modules as input. I doubt
Benoit's tools read tree views as input.

/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] WGLC - draft-ietf-netmod-yang-tree-diagrams


Hi Tom,


On 17/01/2018 09:52, t.petch wrote:

- Original Message -
From: "Alexander Clemm" 
Sent: Wednesday, January 17, 2018 2:20 AM


+1 to (2) as preference, followed by (1).  I don't think (3) is needed

here.  The purpose is to make this human-readable and provide readers a
good sense of the overall structure.



That's what I thought until Benoit said, and Robert agreed, that

'In the end, the tree view should be browsed with tooling.'
The text based YANG tree diagram (i.e. covered by this draft) doesn't 
need to be browsable by tooling.  The purpose of these diagrams should 
be to go in text documents to help explain and illustrate (to human 
readers) the structure of a YANG model.


By "In the end, the tree view should be browsed with tooling.", what I 
mean is that I think that tools like YANG catalog will be the long term 
way of interacting with and browsing YANG modules.  For example, the 
link below for the RIP module.


https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip

This provides an interactive GUI "tree view" of a YANG model, which 
should be structurally equivalent as the text tree diagram, but 
otherwise the information may be represented in a more visual way. This 
will become even more powerful when all of the standard YANG modules are 
available together in a single browsable tree.


Hopefully, that clarifies my previous comment.

Thanks,
Rob



i.e. the tree view should be machine readable after which something is
produced for human consumption; not a view I share.

Tom Petch


The authoritative specification is still the .yang itself.  Providing
some guidance for how to represent the tree is good but let's not
over-engineer this; I believe retaining some flexibility is good.

--- Alex


-Original Message-

...

Does anyone else have an opinion on this?  I can see three
alternatives:

1) allow any number of addtional spaces
2) allow any number of addtional spaces + define a suggested
   alignment algorithm
3) mandate the alignment algorithm

Definition of symbols should be precise/consistent, so that readers

can

consistently interpret tree diagrams.

I think that flexibility in layout should be OK, but the draft

should provide

guideline to ensure the output is readable, and likely to be broadly

consistent

(since consistency aids readability).

If the IETF data modeling group is trying to specify text output

precisely

enough that it can be screen scraped then we may want to consider

whether

we are focusing on the right solution ;-)

In summary, (2) is my preference, followed by (1), followed by (3).

Thanks,
Rob



/martin

.



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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

Hi,

Robert Wilton  wrote:
> On 17/01/2018 07:43, Martin Bjorklund wrote:
> > Alexander Clemm  wrote:
> >> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
> >> here.  The purpose is to make this human-readable and provide readers
> >> a good sense of the overall structure.  The authoritative
> >> specification is still the .yang itself.  Providing some guidance for
> >> how to represent the tree is good but let's not over-engineer this; I
> >> believe retaining some flexibility is good.
> > The last sentence summarizes my personal view.  I prefer (1), followed
> > by (2).
> OK, so the "Providing some guidance for how to represent the tree is
> good" is along the lines of what I was thinking for the "algorithm"
> would be for 2.
> 
> E.g. something along the lines of:
> "Arbitrary whitespace is allowed between any of the whitespace
> separated fields (e.g.  and ).  Additional whitespace may
> be used to column align fields (e.g. within a list or container) to
> improve readability".

This is fine with me.  It is something in between (1) and (2) which
people preferred.  I will add this text.

> But just saying implementations can use arbitrary whitespace is also
> fine with me.  I certainly err on the side of not being overly
> prescriptive on this ..
> 
> I'm not really a fan of the comparing tree output as a method of
> verifying a YANG parser idea.

This is getting off-topic, but if an implementor wants to do this in
order to verify his implementation, go for it!  It doesn't have to be
discussed on this ML.  Speaking from own experience of two different
implementations, I can tell you that it is a useful test to do ;-)


/martin

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

2018-01-17 Thread t.petch

- Original Message -
From: "Alexander Clemm" 
Sent: Wednesday, January 17, 2018 2:20 AM

> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
here.  The purpose is to make this human-readable and provide readers a
good sense of the overall structure.



That's what I thought until Benoit said, and Robert agreed, that

'In the end, the tree view should be browsed with tooling.'

i.e. the tree view should be machine readable after which something is
produced for human consumption; not a view I share.

Tom Petch


   The authoritative specification is still the .yang itself.  Providing
some guidance for how to represent the tree is good but let's not
over-engineer this; I believe retaining some flexibility is good.
>
> --- Alex
>
> > -Original Message-
> ...
> > > Does anyone else have an opinion on this?  I can see three
> > > alternatives:
> > >
> > >1) allow any number of addtional spaces
> > >2) allow any number of addtional spaces + define a suggested
> > >   alignment algorithm
> > >3) mandate the alignment algorithm
> >
> > Definition of symbols should be precise/consistent, so that readers
can
> > consistently interpret tree diagrams.
> >
> > I think that flexibility in layout should be OK, but the draft
should provide
> > guideline to ensure the output is readable, and likely to be broadly
consistent
> > (since consistency aids readability).
> >
> > If the IETF data modeling group is trying to specify text output
precisely
> > enough that it can be screen scraped then we may want to consider
whether
> > we are focusing on the right solution ;-)
> >
> > In summary, (2) is my preference, followed by (1), followed by (3).
> >
> > Thanks,
> > Rob
> >
> > >
> > >
> > > /martin

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams




On 17/01/2018 07:43, Martin Bjorklund wrote:

Alexander Clemm  wrote:

+1 to (2) as preference, followed by (1).  I don't think (3) is needed
here.  The purpose is to make this human-readable and provide readers
a good sense of the overall structure.  The authoritative
specification is still the .yang itself.  Providing some guidance for
how to represent the tree is good but let's not over-engineer this; I
believe retaining some flexibility is good.

The last sentence summarizes my personal view.  I prefer (1), followed
by (2).
OK, so the "Providing some guidance for how to represent the tree is 
good" is along the lines of what I was thinking for the "algorithm" 
would be for 2.


E.g. something along the lines of:
"Arbitrary whitespace is allowed between any of the whitespace separated 
fields (e.g.  and ).  Additional whitespace may be used to 
column align fields (e.g. within a list or container) to improve 
readability".


But just saying implementations can use arbitrary whitespace is also 
fine with me.  I certainly err on the side of not being overly 
prescriptive on this ..


I'm not really a fan of the comparing tree output as a method of 
verifying a YANG parser idea.


Thanks,
Rob





/martin


--- Alex


-Original Message-

...

Does anyone else have an opinion on this?  I can see three
alternatives:

1) allow any number of addtional spaces
2) allow any number of addtional spaces + define a suggested
   alignment algorithm
3) mandate the alignment algorithm

Definition of symbols should be precise/consistent, so that readers
can
consistently interpret tree diagrams.

I think that flexibility in layout should be OK, but the draft should
provide
guideline to ensure the output is readable, and likely to be broadly
consistent
(since consistency aids readability).

If the IETF data modeling group is trying to specify text output
precisely
enough that it can be screen scraped then we may want to consider
whether
we are focusing on the right solution ;-)

In summary, (2) is my preference, followed by (1), followed by (3).

Thanks,
Rob



/martin

___
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

.



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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

On Wed, Jan 17, 2018 at 10:08:02AM +0100, Vladimir Vassilev wrote:
> 
> The advantage I see is that 'uses' and 'augments' are resolved in the tree
> output. For example one can not cach bug in the reolution of the configure
> flag in a uses expanded under case with "configure false;" by generating
> YANG with unresolved 'uses'.  Another example - one can not represent the
> result of multiple modules augmenting e.g. /interfaces with a YANG module.
> The only universal representation is the YANG tree.
>

But then the tree diagram leave out tons of other details. Anyway, if
you insist on using tree diagrams for testing, your test can simply
tolerate white space differences.

/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] WGLC - draft-ietf-netmod-yang-tree-diagrams

2018-01-17 Thread Vladimir Vassilev




On 01/16/2018 09:06 PM, Juergen Schoenwaelder wrote:

On Tue, Jan 16, 2018 at 08:19:38PM +0100, Vladimir Vassilev wrote:

As for the automated validation of the tree diagrams as an added value to
the human readability I have the following thoughts. I would like to be able
to compare unlimited line length tree outputs generated by different YANG
compilers for equality. This is mainly a way to have some partial common
denominator output for validating YANG is correctly compiled which we did
not have until now. For example as soon as I have support for Schema mount I
would compare the tree output with another tool known to work and add some
testcases based on that. I do not see any automated alternative for doing
this except writing NETCONF chat scripts (also module specific), or writing
not only YANG module specific but also API specific test cases as 3rd
option. 1) does not compromise this automated validation option since space
sequences can be collapsed to single space. If the alignment algorithm was
creating a possibility for nontrivial output variation then I would have
supported strongly 3) but this is not the current case.


If you want to make sure a YANG compiler is correct, simply write a
backend that generates a serialized YANG module in canonical
form. They YANG modules should be the same. Determining YANG compiler
correctness by comparing tree diagrams does not seem to be a
convincing approach since tree diagrams by design leave many details
out.
The advantage I see is that 'uses' and 'augments' are resolved in the 
tree output. For example one can not cach bug in the reolution of the 
configure flag in a uses expanded under case with "configure false;" by 
generating YANG with unresolved 'uses'.  Another example - one can not 
represent the result of multiple modules augmenting e.g. /interfaces 
with a YANG module. The only universal representation is the YANG tree.


Vladimir

/js



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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt

2018-01-17 Thread Benoit Claise


On 1/17/2018 9:59 AM, Martin Bjorklund wrote:

Hi,

These errors seem to be issues with the tool, not the draft.

Good to know Martin. Thanks.

Regards, Benoit



/martin

Benoit Claise  wrote:

Hi Mahesh,

There is an error with the yangdump-pro:

Error: Feature 'match-on-eth and match-on-ipv4' not found for
if-feature statement
ietf-access-control-l...@2018-01-16.yang:242.16: error(250):
definition not found

Error: Feature 'match-on-eth and match-on-ipv6' not found for
if-feature statement
ietf-access-control-l...@2018-01-16.yang:248.16: error(250):
definition not found

Error: Feature 'match-on-eth and match-on-ipv4
and match-on-ipv6' not found for if-feature statement
ietf-access-control-l...@2018-01-16.yang:253.16: error(250):
definition not found

***
*** 3 Errors, 0 Warnings

See http://www.claise.be/IETFYANGPageCompilation.html

Also, you want to inform and help the dependent YANG modules (Yang
impact analysis for draft-ietf-netmod-acl-model
)
validate correctly.

Regards, Benoit

This version of the drafts addresses comments received during the last
run of the LC. We, the authors, believe that this document is ready
for LC.


On Jan 16, 2018, at 7:11 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Network Modeling WG of the IETF.

 Title   : Network Access Control List (ACL) YANG Data Model
 Authors : Mahesh Jethanandani
   Lisa Huang
   Sonal Agarwal
   Dana Blair
Filename: draft-ietf-netmod-acl-model-15.txt
Pages   : 51
Date: 2018-01-16

Abstract:
This document describes a data model of Access Control List (ACL)
basic building blocks.

Editorial Note (To be removed by RFC Editor)

This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication.  This note
summarizes all of the substitutions that are needed.  Please note
that no other RFC Editor instructions are specified anywhere else in
this document.

Artwork in this document contains shorthand references to drafts in
progress.  Please apply the following replacements

o  "" --> the assigned RFC value for this draft both in this
   draft and in the YANG models under the revision statement.

o  Revision date in model needs to get updated with the date the
   draft gets approved.  The date also needs to get reflected on the
   line with .


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15


Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Mahesh Jethanandani
mjethanand...@gmail.com

___
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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt

Hi,

These errors seem to be issues with the tool, not the draft.


/martin

Benoit Claise  wrote:
> Hi Mahesh,
> 
> There is an error with the yangdump-pro:
> 
>Error: Feature 'match-on-eth and match-on-ipv4' not found for
>if-feature statement
>ietf-access-control-l...@2018-01-16.yang:242.16: error(250):
>definition not found
> 
>Error: Feature 'match-on-eth and match-on-ipv6' not found for
>if-feature statement
>ietf-access-control-l...@2018-01-16.yang:248.16: error(250):
>definition not found
> 
>Error: Feature 'match-on-eth and match-on-ipv4
>and match-on-ipv6' not found for if-feature statement
>ietf-access-control-l...@2018-01-16.yang:253.16: error(250):
>definition not found
> 
>***
>*** 3 Errors, 0 Warnings
> 
> See http://www.claise.be/IETFYANGPageCompilation.html
> 
> Also, you want to inform and help the dependent YANG modules (Yang
> impact analysis for draft-ietf-netmod-acl-model
> )
> validate correctly.
> 
> Regards, Benoit
> > This version of the drafts addresses comments received during the last
> > run of the LC. We, the authors, believe that this document is ready
> > for LC.
> >
> >> On Jan 16, 2018, at 7:11 PM, internet-dra...@ietf.org wrote:
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >> This draft is a work item of the Network Modeling WG of the IETF.
> >>
> >> Title   : Network Access Control List (ACL) YANG Data Model
> >> Authors : Mahesh Jethanandani
> >>   Lisa Huang
> >>   Sonal Agarwal
> >>   Dana Blair
> >>Filename: draft-ietf-netmod-acl-model-15.txt
> >>Pages   : 51
> >>Date: 2018-01-16
> >>
> >> Abstract:
> >>This document describes a data model of Access Control List (ACL)
> >>basic building blocks.
> >>
> >>Editorial Note (To be removed by RFC Editor)
> >>
> >>This draft contains many placeholder values that need to be replaced
> >>with finalized values at the time of publication.  This note
> >>summarizes all of the substitutions that are needed.  Please note
> >>that no other RFC Editor instructions are specified anywhere else in
> >>this document.
> >>
> >>Artwork in this document contains shorthand references to drafts in
> >>progress.  Please apply the following replacements
> >>
> >>o  "" --> the assigned RFC value for this draft both in this
> >>   draft and in the YANG models under the revision statement.
> >>
> >>o  Revision date in model needs to get updated with the date the
> >>   draft gets approved.  The date also needs to get reflected on the
> >>   line with .
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
> >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> > Mahesh Jethanandani
> > mjethanand...@gmail.com
> >
> > ___
> > 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

Re: [netmod] schema mount and YANG library

On Wed, 2018-01-17 at 09:27 +0100, Juergen Schoenwaelder wrote:
> On Wed, Jan 17, 2018 at 09:04:29AM +0100, Ladislav Lhotka wrote:
> > > Lada,
> > >  Understanding impact of your proposal on the following would be 
> > > quite helpful:
> > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ (pub
> > > requested)
> > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ (pub
> > >  requested)
> > 
> > In these two drafts, the examples in their appendices have to be updated.
> > 
> > > https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/
> > 
> > AFAICT, there is no impact on this draft.
> 
> Ideally data models should be decoupled from the mechanics with which
> the (datastore) schema is announced.

Agreed, and that's why the l3vpn draft is unaffected. The LNE and NI drafts
demonstrate in the appendices how the entire data model is constructed via
schema mount, so this would change.

Lada 

> 
> /js
> 
-- 
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] WGLC - draft-ietf-netmod-yang-tree-diagrams

On Wed, Jan 17, 2018 at 08:43:18AM +0100, Martin Bjorklund wrote:
> Alexander Clemm  wrote:
> > +1 to (2) as preference, followed by (1).  I don't think (3) is needed
> > here.  The purpose is to make this human-readable and provide readers
> > a good sense of the overall structure.  The authoritative
> > specification is still the .yang itself.  Providing some guidance for
> > how to represent the tree is good but let's not over-engineer this; I
> > believe retaining some flexibility is good.
> 
> The last sentence summarizes my personal view.  I prefer (1), followed
> by (2).

+1

/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] schema mount and YANG library

On Wed, Jan 17, 2018 at 09:04:29AM +0100, Ladislav Lhotka wrote:
> > Lada,
> >      Understanding impact of your proposal on the following would be 
> > quite helpful:
> > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ (pub requested)
> > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ (pub
> >  requested)
> 
> In these two drafts, the examples in their appendices have to be updated.
> 
> > https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/
> 
> AFAICT, there is no impact on this draft.

Ideally data models should be decoupled from the mechanics with which
the (datastore) schema is announced.

/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] schema mount and YANG library

Lou Berger  wrote:
> 
> 
> On 1/16/2018 11:15 AM, Robert Wilton wrote:
> >
> > On 16/01/2018 15:50, Martin Bjorklund wrote:
> >> Lou Berger  wrote:
> >>> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> >>> ... (trimming to topic)
> >>> rejectected by the WG multiple times.  FWIW there are drafts
> >>> already
> >>> with
> >> No at all. The first and last time I proposed this was on 15
> >> December
> >> 2017:
> >>
> >> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
> >>
> > Oh, I certainly would call you proposing that the schema for inline
> > be
> > part of the rest of the schema Mount module well before that. I'm
> > sure
> > I can dig up mail / slides it really necessary...
>  I don't think this has been proposed before.  All previous proposals
>  were basically variants on what is now "use-schema", which works fine
>  when all instances have the same schema.  This new proposal solves 
>  the
>  issue with different schemas in different instances.
> 
> >>> I thought the previous proposals that as well, so don't see material
> >>> difference - at least from the usage standpoint. I also don't see why
> >>> the previous arguments that resulted in consensus for using Yang
> >>> Library underneath the an in line Mount Point don't apply.
> >> B/c it doesn't work well with the NMDA.  You can't mount yang library
> >> in the configuration datastores; it has to be mounted in operational.
> >> With meta-data, you can actually report the correct schema even in
> >> running.  (This is actually true also for pre-NMDA systems).
> >>
> > Understood and agree there is nothing new here and the current version
> > of SM (including inline) has the same limitation as rfc7895, and I'd
> > expect it to behave the same once we have rfc7985bis -- in fact the
> > inline case "just works" with YL-bis as defined today.
> >>> Martin,
> >>>
> >>> you didn't respond to this point.
> >> I agree, it works for non-NMDA servers. But see below.
> >>
> > The argument I recall being the key point on inline was handling the
> > large variety of possible different implementation approaches for
> > modules using inline.
>  I think these still are covered.
> 
> > For example an LNE that is implemented using
> > VMs which can be managed by the host at different times of the VMs
> > operational life cycle based on customer/provider requirements.  I
> > really don't see how YL-bis has any bearing on this point and
>  Using the new proposed meta data annotation together with the new YL
>  means that SM can support the use case above also in an NMDA server.
>  I think the new proposed solution covers more use cases than the
>  previous solution.
> >>> how so?  The inline mount point would contain YL-bis and have the same
> >>> information there, just scoped for the mount point.  It's true a
> >>> client would need to understand the mount point's schema only upon
> >>> parsing the YL under the mount point and this schema could not be
> >>> shared across inline mount points.  But this is as was discussed in
> >>> the past and unchanged from YL.
> >>>
>  Do you think that there is any use case that the proposed solution
>  cannot handle, but the previous solution did?
> >>> yes.  with VM/container technologies the YL / schema can change under
> >>> the mount point from time to time during normal operation (i.e.,
> >>> during runtime, no reboot) and, in some implementations, may require
> >>> some level of rpc operation to access even the schema.  The new (and
> >>> previously proposed approach) of having inline schema available from
> >>> the top level greatly complicates these cases.  Also keep in mind that
> >>> there will be cases where the ability to access information under an
> >>> inline mount point will dynamically change in operation (and top level
> >>> YL would need to remove schema information for the inline mount
> >>> point.)  As before, from the usage standpoint, these changes don't
> >>> provide a whole lot of value and seem to optimizing for something not
> >>> needed in the inline case.
> >> I think this is an implementation issue, rather than a problem with
> >> the proposed mechanism, and it is present in the current solution as
> >> well.  An implementation that can handle dynamically changing mounted
> >> YLs in the current solution can do that in the new solution as well.
> >>
> > I think
> > it is incumbent upon those revisiting past/closed WG decisions (in
> > this case, inline schema being represented by YL) to argue why the
> > decision needs to be revisited.
>  I'm repeating my self: b/c the current solution doesn't work well with
>  the NMDA.
> >>> I simply don't understand

Re: [netmod] schema mount and YANG library