[netmod] yang-next

[Andy Bierman]

Hi,

I still support the formation of a design team to
review the yang-next issues

https://github.com/netmod-wg/yang-next/issues

I mean a team of YANG experts that is willing to
prepare for the meeting, not a conf-call with 20 people
where only 3 people have bothered to review any issues.

The 1.2 vs. 2.0 issue is a 2nd order problem.
If any compelling features are found that are worth breaking
backward compatibility with YANG 1.1, then maybe 2.0 is
worth it, but the goal is that 1.1 will convert automatically to 1.2.

None of the feature requests are that compelling, but IMO
the community is expecting incremental improvements,
and there are plenty of those to consider.

The WG should either make an informed decision about yang-next
or archive the repo and tell the community there will not be any
new version of YANG.

Andy
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

Re: [netmod] YANG next

[Ladislav Lhotka]

On Thu, 2019-07-25 at 07:41 -0700, Andy Bierman wrote:
> Hi,
> 
> Was this a big topic at the side meeting?

I think I wrote quite clearly that YANG itself was no topic there - except
perhaps complaints regarding the IETF/OpenConfig schism.

This fact means to me that the problem is not missing features in YANG but
rather missing YANG modules at all different places, and so making a new version
of YANG doesn't seem like a good idea to me - we should leave existing module
writers in peace and encourage new ones. And a better specification could
certainly help with the latter. 

> The issues blocking NMDA, schema-mount, and other deployment problems
> are related to YANG document organization?  I doubt it.

Well, people at that meeting probably already made their way through the
existing specs, although I seriously doubt that they understand all the dark
corners. The problems is with newcomers, who may be deterred by the existing
complexity and turn to something else - and alternatives do exist.

> 
> So how would this work?
> There will be 2 versions of YANG 1.1?
> If old YANG 1.1 is equivalent to new YANG 1.1, can a developer safely ignore
> the new RFCs?
> If not, then something changed that was not supposed to change.

The new RFCs may obsolete/update 7950 as necessary. I assume, however, that some
limited changes may be necessary, so it may in fact be YANG 1.2 that's described
in the new RFCs. I don't think it is a big deal.
> 
> The old YANG 1.1 RFC will be obsolete and the 2 (or more) new YANG 1.1 RFCs
> will replace it?
> Then of course all the RFCs that reference RFC 7950 might have to be updated
> so the subject matter
> is cited from the correct new YANG 1.1 RFC.
> 
> IMO this will only serve to confuse the end-users and offer them no real
> benefit at all.

I have a different opinion.

> As for finishing quickly because the NETMOD WG is so fast and has nothing
> better to work on anyway...  sure.

Well, if you compare time spent on YANG 1.1, it was considerably shorter than
the time spent of many modules, and not only in NETMOD - routing, acl, ospf, is-
is, to name a few.

Lada

> 
> 
> Andy
> 
> 
> 
> On Thu, Jul 25, 2019 at 5:56 AM Rob Wilton (rwilton) 
> wrote:
> > I also think that there is significant value to splitting the NETCONF and
> > XML specification out of RFC 7950 (but keeping XML examples).  I think that
> > this may be beneficial to YANG’s longevity, and I’m sure that it would make
> > it easier to maintain and extend the NETCONF/RESTCONF/YANG document set in
> > future.
> > 
> >  
> > 
> > Thanks,
> > 
> > Rob
> > 
> >  
> > 
> >  
> > 
> > From: netmod  On Behalf Of Andy Bierman
> > Sent: 24 July 2019 14:32
> > To: Kent Watsen 
> > Cc: net...@ietf..org
> > Subject: Re: [netmod] YANG next
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> > On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen  wrote:
> > 
> > >  
> > > 
> > > > > > So you want to work on YANG 1.2, but just the parts you want to
> > > > > > change? ;-)
> > > > > > 
> > > > > 
> > > > > I am actually fine with not doing any changes to YANG 1.1 at all,
> > > > > except perhaps
> > > > > bug fixes. This doesn't necessarily mean closing the NETMOD WG, it
> > > > > would IMO be
> > > > > immensely useful to rewrite the language specification and remove
> > > > > NETCONF- and
> > > > > XML-specific part.
> > > > > 
> > > > 
> > > > +1. There are plenty of ambiguities and NETCONF/XML pollution in the
> > > > spec. Having the specifications in a DAG would be immensely useful :)
> > > > 
> > > 
> > >  
> > > 
> > > Agreed and I should've mentioned before that Martin said in Prague that
> > > he'd already started this effort, seeing it as a necessary pre-step before
> > > making other changes..  I'm unsure if the intention is to release this by
> > > itself as an RFC 7950 bis but, if looking for a minimal change, that might
> > > be it.  The next rung up would be to just add clarifications.  The next
> > > rung up from there would be to add only backwards-compatible changes
> > > (currently targeted by [1]).  The last rung being to also target NBC
> > > changes (there's no consensus to do this).
> > > 
> > >  
> > > 
> > 
> >  
> > 
> > This WG sure likes to spend time refactoring documents.
> > 
> > Moving lots of text will create bugs and strong coupling, and 

Re: [netmod] YANG next

[Andy Bierman]

Hi,

Was this a big topic at the side meeting?
The issues blocking NMDA, schema-mount, and other deployment problems
are related to YANG document organization?  I doubt it.

So how would this work?
There will be 2 versions of YANG 1.1?
If old YANG 1.1 is equivalent to new YANG 1.1, can a developer safely
ignore the new RFCs?
If not, then something changed that was not supposed to change.

The old YANG 1.1 RFC will be obsolete and the 2 (or more) new YANG 1.1 RFCs
will replace it?
Then of course all the RFCs that reference RFC 7950 might have to be
updated so the subject matter
is cited from the correct new YANG 1.1 RFC.

IMO this will only serve to confuse the end-users and offer them no real
benefit at all.
As for finishing quickly because the NETMOD WG is so fast and has nothing
better to work on anyway...  sure.


Andy



On Thu, Jul 25, 2019 at 5:56 AM Rob Wilton (rwilton) 
wrote:

> I also think that there is significant value to splitting the NETCONF and
> XML specification out of RFC 7950 (but keeping XML examples).  I think that
> this may be beneficial to YANG’s longevity, and I’m sure that it would make
> it easier to maintain and extend the NETCONF/RESTCONF/YANG document set in
> future.
>
>
>
> Thanks,
>
> Rob
>
>
>
>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* 24 July 2019 14:32
> *To:* Kent Watsen 
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] YANG next
>
>
>
>
>
>
>
> On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen  wrote:
>
>
>
> So you want to work on YANG 1.2, but just the parts you want to change? ;-)
>
> I am actually fine with not doing any changes to YANG 1.1 at all, except
> perhaps
> bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would
> IMO be
> immensely useful to rewrite the language specification and remove NETCONF-
> and
> XML-specific part.
>
>
> +1. There are plenty of ambiguities and NETCONF/XML pollution in the
> spec. Having the specifications in a DAG would be immensely useful :)
>
>
>
> Agreed and I should've mentioned before that Martin said in Prague that
> he'd already started this effort, seeing it as a necessary pre-step before
> making other changes.  I'm unsure if the intention is to release this by
> itself as an RFC 7950 bis but, if looking for a minimal change, that might
> be it.  The next rung up would be to just add clarifications.  The next
> rung up from there would be to add only backwards-compatible changes
> (currently targeted by [1]).  The last rung being to also target NBC
> changes (there's no consensus to do this).
>
>
>
>
>
> This WG sure likes to spend time refactoring documents.
>
> Moving lots of text will create bugs and strong coupling, and only help
> the standards purists.
>
> It will be a lot of work for the WG and IESG to review such a massive
> document split,
>
> and in the end we have no improvement in YANG, just more RFCs to read.
>
>
>
> Andy
>
>
>
> [1] https://github.com/netmod-wg/yang-next/projects/2
> <https://github..com/netmod-wg/yang-next/projects/2>
>
>
>
> Kent
>
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG next

[Ladislav Lhotka]

On Thu, 2019-07-25 at 12:56 +, Rob Wilton (rwilton) wrote:
> I also think that there is significant value to splitting the NETCONF and XML
> specification out of RFC 7950 (but keeping XML examples).  I think that this
> may be beneficial to YANG’s longevity, and I’m sure that it would make it
> easier to maintain and extend the NETCONF/RESTCONF/YANG document set in
> future.

Agreed. And if we do it without changing YANG (except for absolute musts, if
there are any), we can reasonably expect that it can be done relatively quickly.

Lada

>  
> Thanks,
> Rob
>  
>  
> From: netmod  On Behalf Of Andy Bierman
> Sent: 24 July 2019 14:32
> To: Kent Watsen 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] YANG next
>  
>  
>  
> On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen  wrote:
> >  
> > > > > So you want to work on YANG 1.2, but just the parts you want to
> > > > > change? ;-)
> > > > 
> > > > I am actually fine with not doing any changes to YANG 1.1 at all, except
> > > > perhaps
> > > > bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would
> > > > IMO be
> > > > immensely useful to rewrite the language specification and remove
> > > > NETCONF- and
> > > > XML-specific part.
> > > 
> > > +1. There are plenty of ambiguities and NETCONF/XML pollution in the
> > > spec. Having the specifications in a DAG would be immensely useful :)
> > 
> >  
> > Agreed and I should've mentioned before that Martin said in Prague that he'd
> > already started this effort, seeing it as a necessary pre-step before making
> > other changes.  I'm unsure if the intention is to release this by itself as
> > an RFC 7950 bis but, if looking for a minimal change, that might be it.  The
> > next rung up would be to just add clarifications.  The next rung up from
> > there would be to add only backwards-compatible changes (currently targeted
> > by [1]).  The last rung being to also target NBC changes (there's no
> > consensus to do this).
> >  
> 
>  
> This WG sure likes to spend time refactoring documents.
> Moving lots of text will create bugs and strong coupling, and only help the
> standards purists.
> It will be a lot of work for the WG and IESG to review such a massive document
> split,
> and in the end we have no improvement in YANG, just more RFCs to read.
>  
> Andy
>  
> > [1] https://github.com/netmod-wg/yang-next/projects/2
> >  
> > Kent 
> >  
> >  
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] YANG next

[Rob Wilton (rwilton)]

I also think that there is significant value to splitting the NETCONF and XML 
specification out of RFC 7950 (but keeping XML examples).  I think that this 
may be beneficial to YANG’s longevity, and I’m sure that it would make it 
easier to maintain and extend the NETCONF/RESTCONF/YANG document set in future.

Thanks,
Rob


From: netmod  On Behalf Of Andy Bierman
Sent: 24 July 2019 14:32
To: Kent Watsen 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG next



On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen 
mailto:k...@watsen.net>> wrote:

So you want to work on YANG 1.2, but just the parts you want to change? ;-)
I am actually fine with not doing any changes to YANG 1.1 at all, except perhaps
bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would IMO be
immensely useful to rewrite the language specification and remove NETCONF- and
XML-specific part.

+1. There are plenty of ambiguities and NETCONF/XML pollution in the
spec. Having the specifications in a DAG would be immensely useful :)

Agreed and I should've mentioned before that Martin said in Prague that he'd 
already started this effort, seeing it as a necessary pre-step before making 
other changes.  I'm unsure if the intention is to release this by itself as an 
RFC 7950 bis but, if looking for a minimal change, that might be it.  The next 
rung up would be to just add clarifications.  The next rung up from there would 
be to add only backwards-compatible changes (currently targeted by [1]).  The 
last rung being to also target NBC changes (there's no consensus to do this).


This WG sure likes to spend time refactoring documents.
Moving lots of text will create bugs and strong coupling, and only help the 
standards purists.
It will be a lot of work for the WG and IESG to review such a massive document 
split,
and in the end we have no improvement in YANG, just more RFCs to read.

Andy

[1] 
https://github.com/netmod-wg/yang-next/projects/2<https://github..com/netmod-wg/yang-next/projects/2>

Kent


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

Re: [netmod] YANG next

[Ladislav Lhotka]

On Wed, 2019-07-24 at 22:37 +0200, Robert Varga wrote:
> On 24/07/2019 20:32, Andy Bierman wrote:
> > On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen  > > wrote:
> > 
> > 
> > > > > So you want to work on YANG 1.2, but just the parts you want to
> > > > > change? ;-)
> > > > I am actually fine with not doing any changes to YANG 1.1 at all,
> > > > except perhaps
> > > > bug fixes. This doesn't necessarily mean closing the NETMOD WG,
> > > > it would IMO be
> > > > immensely useful to rewrite the language specification and remove
> > > > NETCONF- and
> > > > XML-specific part.
> > > 
> > > +1. There are plenty of ambiguities and NETCONF/XML pollution in the
> > > spec. Having the specifications in a DAG would be immensely useful :)
> > 
> > Agreed and I should've mentioned before that Martin said in Prague
> > that he'd already started this effort, seeing it as a necessary
> > pre-step before making other changes.  I'm unsure if the intention
> > is to release this by itself as an RFC 7950 bis but, if looking for
> > a minimal change, that might be it.  The next rung up would be to
> > just add clarifications.  The next rung up from there would be to
> > add only backwards-compatible changes (currently targeted by [1]). 
> > The last rung being to also target NBC changes (there's no consensus
> > to do this).
> > 
> > 
> > This WG sure likes to spend time refactoring documents.
> 
> Sorry, I am not watching very closely so I have not noticed.
> 
> I regard the NETCONF coupling in RFC6020/RFC7950 as technical debt,
> which when addressed will allow us to have better discussions about
> modeling intent vs. XML representation.

Absolutely. Also note that in RFC 7950 we even don't have a sound definition of
an instance data tree.

> 
> > Moving lots of text will create bugs and strong coupling, and only help
> > the standards purists.
> 
> Not necessarily. I agree with limiting the amount (and type) of text
> being moved and modifications done in between.
> 
> > It will be a lot of work for the WG and IESG to review such a massive
> > document split,
> > and in the end we have no improvement in YANG, just more RFCs to read.
> 
> No improvement in to YANG in terms of number of features, yes.
> 
> Even if it ends up being more documents, if they are smaller and more
> logically structured, they are more approachable.

Right. The base YANG spec should only define the language and rules for
validating instance data.

> 
> Reading RFC7950 (216 pages) is far from sufficient for understanding
> YANG, as you also need to understand NETCONF, which leads you down the
> RFC6241 rabbit hole.
> 
> If we can get a more approachable first document, lowering the entry
> barrier will be beneficial to people outside the WG(s).

I again fully agree. The entry barrier is unnecessarily high, which may not be
apparent to vintage members of the NETCONF/NETMOD gang.

Lada

> 
> Regards,
> Robert
> 
-- 
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] YANG next

[Balázs Lengyel]

+1, Balazs

 

From: netmod  On Behalf Of Andy Bierman
Sent: 2019. július 24., szerda 14:32
To: Kent Watsen 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG next

 

 

 

On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen mailto:k...@watsen.net> > wrote:

 

So you want to work on YANG 1.2, but just the parts you want to change? ;-)

I am actually fine with not doing any changes to YANG 1.1 at all, except perhaps
bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would IMO be
immensely useful to rewrite the language specification and remove NETCONF- and
XML-specific part.


+1. There are plenty of ambiguities and NETCONF/XML pollution in the
spec. Having the specifications in a DAG would be immensely useful :)

 

Agreed and I should've mentioned before that Martin said in Prague that he'd 
already started this effort, seeing it as a necessary pre-step before making 
other changes.  I'm unsure if the intention is to release this by itself as an 
RFC 7950 bis but, if looking for a minimal change, that might be it.  The next 
rung up would be to just add clarifications.  The next rung up from there would 
be to add only backwards-compatible changes (currently targeted by [1]).  The 
last rung being to also target NBC changes (there's no consensus to do this).

 

 

This WG sure likes to spend time refactoring documents.

Moving lots of text will create bugs and strong coupling, and only help the 
standards purists.

It will be a lot of work for the WG and IESG to review such a massive document 
split,

and in the end we have no improvement in YANG, just more RFCs to read.

 

Andy

 

[1] https://github.com/netmod-wg/yang-next/projects/2 
<https://github..com/netmod-wg/yang-next/projects/2> 

 

Kent 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG next

[Robert Varga]

On 24/07/2019 20:32, Andy Bierman wrote:
> On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen  > wrote:
> 
> 
 So you want to work on YANG 1.2, but just the parts you want to
 change? ;-)
>>> I am actually fine with not doing any changes to YANG 1.1 at all,
>>> except perhaps
>>> bug fixes. This doesn't necessarily mean closing the NETMOD WG,
>>> it would IMO be
>>> immensely useful to rewrite the language specification and remove
>>> NETCONF- and
>>> XML-specific part.
>>
>> +1. There are plenty of ambiguities and NETCONF/XML pollution in the
>> spec. Having the specifications in a DAG would be immensely useful :)
> 
> Agreed and I should've mentioned before that Martin said in Prague
> that he'd already started this effort, seeing it as a necessary
> pre-step before making other changes.  I'm unsure if the intention
> is to release this by itself as an RFC 7950 bis but, if looking for
> a minimal change, that might be it.  The next rung up would be to
> just add clarifications.  The next rung up from there would be to
> add only backwards-compatible changes (currently targeted by [1]). 
> The last rung being to also target NBC changes (there's no consensus
> to do this).
> 
> 
> This WG sure likes to spend time refactoring documents.

Sorry, I am not watching very closely so I have not noticed.

I regard the NETCONF coupling in RFC6020/RFC7950 as technical debt,
which when addressed will allow us to have better discussions about
modeling intent vs. XML representation.

> Moving lots of text will create bugs and strong coupling, and only help
> the standards purists.

Not necessarily. I agree with limiting the amount (and type) of text
being moved and modifications done in between.

> It will be a lot of work for the WG and IESG to review such a massive
> document split,
> and in the end we have no improvement in YANG, just more RFCs to read.

No improvement in to YANG in terms of number of features, yes.

Even if it ends up being more documents, if they are smaller and more
logically structured, they are more approachable.

Reading RFC7950 (216 pages) is far from sufficient for understanding
YANG, as you also need to understand NETCONF, which leads you down the
RFC6241 rabbit hole.

If we can get a more approachable first document, lowering the entry
barrier will be beneficial to people outside the WG(s).

Regards,
Robert



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

Re: [netmod] YANG next

[Andy Bierman]

On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen  wrote:

>
> So you want to work on YANG 1.2, but just the parts you want to change? ;-)
>
> I am actually fine with not doing any changes to YANG 1.1 at all, except
> perhaps
> bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would
> IMO be
> immensely useful to rewrite the language specification and remove NETCONF-
> and
> XML-specific part.
>
>
> +1. There are plenty of ambiguities and NETCONF/XML pollution in the
> spec. Having the specifications in a DAG would be immensely useful :)
>
>
> Agreed and I should've mentioned before that Martin said in Prague that
> he'd already started this effort, seeing it as a necessary pre-step before
> making other changes.  I'm unsure if the intention is to release this by
> itself as an RFC 7950 bis but, if looking for a minimal change, that might
> be it.  The next rung up would be to just add clarifications.  The next
> rung up from there would be to add only backwards-compatible changes
> (currently targeted by [1]).  The last rung being to also target NBC
> changes (there's no consensus to do this).
>
>
This WG sure likes to spend time refactoring documents.
Moving lots of text will create bugs and strong coupling, and only help the
standards purists.
It will be a lot of work for the WG and IESG to review such a massive
document split,
and in the end we have no improvement in YANG, just more RFCs to read.

Andy

[1] https://github.com/netmod-wg/yang-next/projects/2
>
> Kent
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG next

[Juergen Schoenwaelder]

On Wed, Jul 24, 2019 at 07:10:23AM -0700, Andy Bierman wrote:
> On Wed, Jul 24, 2019 at 6:52 AM Ladislav Lhotka  wrote:
> 
> > Juergen Schoenwaelder  writes:
> >
> > > On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote:
> > >>
> > >> This problem is actually not limited to YANG itself - people are
> > reporting
> > >> problems with the transition to NMDA.
> > >>
> > >
> > > The YANG update from 1 to 1.1 mostly affected compiler writers - and
> > > to a much lesser extend module authors and module implementors. NMDA,
> > > affects client and server implementors much more directly, additional
> > > instrumentation on the server side needs to be written, application
> > > logic on the client side needs to be adjusted. NMDA is an evolution of
> > > architectural principles and this already indicates that there is a
> > > certain investment to make.
> >
> > But both updates induced some changes in YANG modules that affect users
> > and integrators. Take ietf-ospf module as an example: it is of course a
> > great addition to the YANG module collection, but in order to use it, all
> > tools have to support
> >
> > - YANG 1.1, e.g. because of the special XPath functions, and
> >
> > - NMDA, because otherwise state data are missing.
> >

I believe the majority of parsers (there were not that many) started
to support YANG 1.1 quite quickly after RFC publication. NMDA support
will take longer and this is not a surprise.

To me, it makes sense to distinguish these two updates. And neithers
says what the update of YANG next will be. Implementation complexity
and transition complexity was one of the things we considered for each
YANG 1.1 improvement.

/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] YANG next

[Kent Watsen]

>>> So you want to work on YANG 1.2, but just the parts you want to change? ;-)
>> I am actually fine with not doing any changes to YANG 1.1 at all, except 
>> perhaps
>> bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would IMO 
>> be
>> immensely useful to rewrite the language specification and remove NETCONF- 
>> and
>> XML-specific part.
> 
> +1. There are plenty of ambiguities and NETCONF/XML pollution in the
> spec. Having the specifications in a DAG would be immensely useful :)


Agreed and I should've mentioned before that Martin said in Prague that he'd 
already started this effort, seeing it as a necessary pre-step before making 
other changes.  I'm unsure if the intention is to release this by itself as an 
RFC 7950 bis but, if looking for a minimal change, that might be it.  The next 
rung up would be to just add clarifications.  The next rung up from there would 
be to add only backwards-compatible changes (currently targeted by [1]).  The 
last rung being to also target NBC changes (there's no consensus to do this).

[1] https://github.com/netmod-wg/yang-next/projects/2 

 
Kent 


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

Re: [netmod] YANG next

[Robert Varga]

On 23/07/2019 23:43, Ladislav Lhotka wrote:
>> So you want to work on YANG 1.2, but just the parts you want to change? ;-)
> I am actually fine with not doing any changes to YANG 1.1 at all, except 
> perhaps
> bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would IMO 
> be
> immensely useful to rewrite the language specification and remove NETCONF- and
> XML-specific part.

+1. There are plenty of ambiguities and NETCONF/XML pollution in the
spec. Having the specifications in a DAG would be immensely useful :)

Regards,
Robert



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

Re: [netmod] YANG next

[Robert Varga]

On 24/07/2019 15:51, Ladislav Lhotka wrote:
> Despite the fact that YANG 1.1 and NMDA are undoubtedly improvements, users 
> may get frustrated if lazy authors (including myself) don't update their 
> tools in a timely manner.

Well, honestly, YANG 1.1, while compatible when viewed from the
perspective of a client processing XML, has a different metamodel than
YANG 1.0.

One example for all: YANG 1.0 metamodel did not require multiple
inheritence anywhere, whereas YANG 1.1 requires it to deal with 'base'
being '0..n' instead of '0..1'.

While it is a relatively simple change on the surface, making it happen
in a software ecosystem (with API stability guarantees, release cycles,
etc.) does frustrate users even in presence of non-lazy authors (who
also get frustrated)...

Regards,
Robert



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

Re: [netmod] YANG next

[Balázs Lengyel]

We already have some RFCs and drafts that propose extensions that would/could 
go into YANG 1.2.  I would like to have an “official” agreement/document/wiki 
that lists what is planned to go into 1.2 whenever it happens. That would help 
us to have a platform that contains a well defined set of additions beyond YANG 
1.1.

Regards Balazs

 

From: netmod  On Behalf Of Andy Bierman
Sent: 2019. július 24., szerda 10:10
To: Juergen Schoenwaelder ; Andy Bierman 
; NETMOD WG 
Subject: Re: [netmod] YANG next

 

 

 

On Wed, Jul 24, 2019 at 6:52 AM Ladislav Lhotka mailto:lho...@nic.cz> > wrote:

Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de> > writes:

> On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote:
>> 
>> This problem is actually not limited to YANG itself - people are reporting
>> problems with the transition to NMDA. 
>>
>
> The YANG update from 1 to 1.1 mostly affected compiler writers - and
> to a much lesser extend module authors and module implementors. NMDA,
> affects client and server implementors much more directly, additional
> instrumentation on the server side needs to be written, application
> logic on the client side needs to be adjusted. NMDA is an evolution of
> architectural principles and this already indicates that there is a
> certain investment to make.

But both updates induced some changes in YANG modules that affect users and 
integrators. Take ietf-ospf module as an example: it is of course a great 
addition to the YANG module collection, but in order to use it, all tools have 
to support

- YANG 1.1, e.g. because of the special XPath functions, and

- NMDA, because otherwise state data are missing.

Despite the fact that YANG 1.1 and NMDA are undoubtedly improvements, users may 
get frustrated if lazy authors (including myself) don't update their tools in a 
timely manner.

>
> If we discuss YANG next, we should compare it to the YANG 1 to 1.1
> transition and not to the NMDA transition. When we started YANG 1.1

Both types of changes may have similar effects on YANG users. 

> work, there were people who said that nobody would implement it. But
> then implementations were adopted relatively fast when we finalized
> YANG 1.1.

When we started YANG 1.1, there were only a few YANG modules around with little 
practical use, so nobody really cared. The situation is now very different.

 

Not that different.

The IETF does not value stability that much.

Maybe customer expectations are different, but some of us have to follow 2 
simple rules:

 

   - Whatever works SHALL continue to work 

   - If you changed how it works, you broke it (even if you fixed it)

 

Some customers even think they should be able to upgrade from any existing 
version to any new version,

and these rules still hold. Therefore every change in server behavior must be 
"opt-in" by the vendor and

maybe the client as well. Instead of automatically upgrading because of course 
you want the spiffy

new features, vendors want the behavior to stay exactly the same (unless they 
choose to change it).

 

There is no real need for YANG 1.2 unless and until NBC changes need to be made,

and we try to avoid doing that.

 

 

Lada

 

 

Andy

 

>
> While a collection of patches (updates) of YANG 1.1 may sound simpler,
> I am not sure this is really true. We will loose a common baseline and
> instead get complexity since we will get systems that all support
> different sets of patches (updates) of YANG 1.1. I believe we are all
> much better off if we have a common baseline language and tools that
> support the common baseline language. Again, if done right, YANG next
> will mostly affect compiler writers and tool makers and not so much
> module authors and implementors.
>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG next

[Andy Bierman]

On Wed, Jul 24, 2019 at 6:52 AM Ladislav Lhotka  wrote:

> Juergen Schoenwaelder  writes:
>
> > On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote:
> >>
> >> This problem is actually not limited to YANG itself - people are
> reporting
> >> problems with the transition to NMDA.
> >>
> >
> > The YANG update from 1 to 1.1 mostly affected compiler writers - and
> > to a much lesser extend module authors and module implementors. NMDA,
> > affects client and server implementors much more directly, additional
> > instrumentation on the server side needs to be written, application
> > logic on the client side needs to be adjusted. NMDA is an evolution of
> > architectural principles and this already indicates that there is a
> > certain investment to make.
>
> But both updates induced some changes in YANG modules that affect users
> and integrators. Take ietf-ospf module as an example: it is of course a
> great addition to the YANG module collection, but in order to use it, all
> tools have to support
>
> - YANG 1.1, e.g. because of the special XPath functions, and
>
> - NMDA, because otherwise state data are missing.
>
> Despite the fact that YANG 1.1 and NMDA are undoubtedly improvements,
> users may get frustrated if lazy authors (including myself) don't update
> their tools in a timely manner.
>
> >
> > If we discuss YANG next, we should compare it to the YANG 1 to 1.1
> > transition and not to the NMDA transition. When we started YANG 1.1
>
> Both types of changes may have similar effects on YANG users.
>
> > work, there were people who said that nobody would implement it. But
> > then implementations were adopted relatively fast when we finalized
> > YANG 1.1.
>
> When we started YANG 1.1, there were only a few YANG modules around with
> little practical use, so nobody really cared. The situation is now very
> different.
>
>
Not that different.
The IETF does not value stability that much.
Maybe customer expectations are different, but some of us have to follow 2
simple rules:

   - Whatever works SHALL continue to work
   - If you changed how it works, you broke it (even if you fixed it)

Some customers even think they should be able to upgrade from any existing
version to any new version,
and these rules still hold. Therefore every change in server behavior must
be "opt-in" by the vendor and
maybe the client as well. Instead of automatically upgrading because of
course you want the spiffy
new features, vendors want the behavior to stay exactly the same (unless
they choose to change it).

There is no real need for YANG 1.2 unless and until NBC changes need to be
made,
and we try to avoid doing that.


Lada
>
>

Andy


> >
> > While a collection of patches (updates) of YANG 1.1 may sound simpler,
> > I am not sure this is really true. We will loose a common baseline and
> > instead get complexity since we will get systems that all support
> > different sets of patches (updates) of YANG 1.1. I believe we are all
> > much better off if we have a common baseline language and tools that
> > support the common baseline language. Again, if done right, YANG next
> > will mostly affect compiler writers and tool makers and not so much
> > module authors and implementors.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
>
> --
> 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] YANG next

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote:
>> 
>> This problem is actually not limited to YANG itself - people are reporting
>> problems with the transition to NMDA. 
>>
>
> The YANG update from 1 to 1.1 mostly affected compiler writers - and
> to a much lesser extend module authors and module implementors. NMDA,
> affects client and server implementors much more directly, additional
> instrumentation on the server side needs to be written, application
> logic on the client side needs to be adjusted. NMDA is an evolution of
> architectural principles and this already indicates that there is a
> certain investment to make.

But both updates induced some changes in YANG modules that affect users and 
integrators. Take ietf-ospf module as an example: it is of course a great 
addition to the YANG module collection, but in order to use it, all tools have 
to support

- YANG 1.1, e.g. because of the special XPath functions, and

- NMDA, because otherwise state data are missing.

Despite the fact that YANG 1.1 and NMDA are undoubtedly improvements, users may 
get frustrated if lazy authors (including myself) don't update their tools in a 
timely manner.

>
> If we discuss YANG next, we should compare it to the YANG 1 to 1.1
> transition and not to the NMDA transition. When we started YANG 1.1

Both types of changes may have similar effects on YANG users. 

> work, there were people who said that nobody would implement it. But
> then implementations were adopted relatively fast when we finalized
> YANG 1.1.

When we started YANG 1.1, there were only a few YANG modules around with little 
practical use, so nobody really cared. The situation is now very different.

Lada

>
> While a collection of patches (updates) of YANG 1.1 may sound simpler,
> I am not sure this is really true. We will loose a common baseline and
> instead get complexity since we will get systems that all support
> different sets of patches (updates) of YANG 1.1. I believe we are all
> much better off if we have a common baseline language and tools that
> support the common baseline language. Again, if done right, YANG next
> will mostly affect compiler writers and tool makers and not so much
> module authors and implementors.
>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
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] YANG next

[Qin Wu]

+1
Separate YANG next from YANG next step discussed in yang side meeting, is it 
the time to call for another workshop in IETF to discuss YANG next and Netconf 
next.


吴钦 Qin
Mobile：+86-13914734360(Mobile Number)
Email：bill...@huawei.com<mailto:bill...@huawei.com>



发件人： Balázs 
Lengyelmailto:balazs.leng...@ericsson.com>>
收件人： Rob Wilton (rwilton)mailto:rwil...@cisco.com>>;Ladislav 
Lhotkamailto:lho...@nic.cz>>;NETMOD 
WGmailto:netmod@ietf.org>>
主题： Re: [netmod] YANG next
时间： 2019-07-23 17:56:45

+1   Balazs

-Original Message-
From: netmod  On Behalf Of Rob Wilton (rwilton)
Sent: 2019. július 23., kedd 17:51
To: Ladislav Lhotka ; NETMOD WG 
Subject: Re: [netmod] YANG next

Hi Lada,

I still think that it makes sense to do YANG Next, on the assumption that it
will take a couple of years to work out, maybe longer if the work doesn't
properly get started until the YANG versioning work has progressed further.

When I look at the YANG Next issue list, I think that there are quite a lot
of things on that list (some of which are quite small) that would be good to
do, and will help modelling efforts.

Thanks,
Rob


-Original Message-
From: netmod  On Behalf Of Ladislav Lhotka
Sent: 23 July 2019 12:03
To: NETMOD WG 
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of
YANG the language, which was not the case at all. However, my personal
conclusion from the meeting is that it would be a total disaster to throw in
a new version of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules
and tools, filling the gaps, coping with NMDA, schema mount, IETF versus
OpenConfig etc. A new YANG version (and modules written in it) would IMO be
extremely counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have
to figure out how to evolve YANG without making waves in the current YANG
pond and let the operators and vendors do their work, without which YANG can
never succeed.

Lada

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

___
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] YANG next

[Qin Wu]

Thanks Adrian for clarification. The goal of YANG side meeting is not to 
discuss YANG-Next but fill the gap with operator community.
Thanks Dan and Adrian to take minutes. I have uploaded to IETF YANG Side 
meeting wiki page. 
To folks who participant in the meeting, thanks for your participation and 
input. If there is any correction needed, please
let us know.
Room: Notre Dame - Tuesday ¶
Occupancy: up to 50 attendees 
Configuration: classroom 
Location: ​Notre Dame 

Meeting NameArea ContactMeeting Description More information 
08:30 Next Step of IETF YANG OPS Area bill.wu@… Discuss the gap between IETF 
YANG and Industry needs The presentation slides and minutes: 
​https://github.com/sunseawq/IETF-YANG-side-meeting 
The relevant draft is 
​https://www.ietf.org/id/draft-wu-model-driven-management-virtualization-05.txt 

Regards!
-Qin

发件人: netmod [netmod-boun...@ietf.org] 代表 Adrian Farrel [adr...@olddog.co.uk]
发送时间: 2019年7月24日 2:14
收件人: 'Ladislav Lhotka'; 'Andy Bierman'
抄送: 'NETMOD WG'
主题: Re: [netmod] YANG next

>> I hope a summary of the meeting is posted to the WG mailing list.
>
> I think so, minutes were taken.

I scribbled.
So did Dan King.
We sent our scribbles to Geng Liang and Qin Wu.
They will process.

It was a side meeting.
As Lou says, it was not part of any existing WG. Nor was it a BoF.

How and where and if the minutes are published is not a question for me to
answer.

Adrian

PS I don't think this was a debate about creating a new version of the YANG
language, and I don't think extensions or modifications to the YANG language
were high on the list of "fixes" to the questions raised in the meeting.
That doesn't mean that debate shouldn't/cannot happen, just that it is not
(highly) relevant to the discussion at hand.


___
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 next

[Balázs Lengyel]

+1   Balazs

-Original Message-
From: netmod  On Behalf Of Rob Wilton (rwilton)
Sent: 2019. július 23., kedd 17:51
To: Ladislav Lhotka ; NETMOD WG 
Subject: Re: [netmod] YANG next

Hi Lada,

I still think that it makes sense to do YANG Next, on the assumption that it
will take a couple of years to work out, maybe longer if the work doesn't
properly get started until the YANG versioning work has progressed further.

When I look at the YANG Next issue list, I think that there are quite a lot
of things on that list (some of which are quite small) that would be good to
do, and will help modelling efforts.

Thanks,
Rob


-Original Message-
From: netmod  On Behalf Of Ladislav Lhotka
Sent: 23 July 2019 12:03
To: NETMOD WG 
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of
YANG the language, which was not the case at all. However, my personal
conclusion from the meeting is that it would be a total disaster to throw in
a new version of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules
and tools, filling the gaps, coping with NMDA, schema mount, IETF versus
OpenConfig etc. A new YANG version (and modules written in it) would IMO be
extremely counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have
to figure out how to evolve YANG without making waves in the current YANG
pond and let the operators and vendors do their work, without which YANG can
never succeed.

Lada

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

___
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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG next

[Rob Wilton (rwilton)]

Hi Lada,

I still think that it makes sense to do YANG Next, on the assumption that it 
will take a couple of years to work out, maybe longer if the work doesn't 
properly get started until the YANG versioning work has progressed further.

When I look at the YANG Next issue list, I think that there are quite a lot of 
things on that list (some of which are quite small) that would be good to do, 
and will help modelling efforts.

Thanks,
Rob


-Original Message-
From: netmod  On Behalf Of Ladislav Lhotka
Sent: 23 July 2019 12:03
To: NETMOD WG 
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was 
somewhat misled into thinking that it would be about future evolution of YANG 
the language, which was not the case at all. However, my personal conclusion 
from the meeting is that it would be a total disaster to throw in a new version 
of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules and 
tools, filling the gaps, coping with NMDA, schema mount, IETF versus OpenConfig 
etc. A new YANG version (and modules written in it) would IMO be extremely 
counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have to 
figure out how to evolve YANG without making waves in the current YANG pond and 
let the operators and vendors do their work, without which YANG can never 
succeed.

Lada

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

___
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 next

[Ladislav Lhotka]

On Tue, 2019-07-23 at 11:35 -0700, Andy Bierman wrote:
> 
> 
> On Tue, Jul 23, 2019 at 11:00 AM Ladislav Lhotka  wrote:
> > On Tue, 2019-07-23 at 09:22 -0700, Andy Bierman wrote:
> > > 
> > > 
> > > On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka  wrote:
> > > > Hi,
> > > > 
> > > > this morning I attended the side meeting "Next Step of IETF YANG". I was
> > > > somewhat misled into thinking that it would be about future evolution of
> > > > YANG
> > > > the language, which was not the case at all. However, my personal
> > conclusion
> > > > from the meeting is that it would be a total disaster to throw in a new
> > > > version
> > > > of YANG within the next few years or so.
> > > > 
> > > 
> > > 
> > > I hope a summary of the meeting is posted to the WG mailing list.
> > 
> > I think so, minutes were taken.
> > 
> > >  
> > > > The operators and equipment vendors are busy putting together YANG
> > modules
> > > > and
> > > > tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> > > > OpenConfig
> > > > etc. A new YANG version (and modules written in it) would IMO be
> > extremely
> > > > counter-productive at this rather turbulent stage.
> > > > 
> > > > So, if we want to continue the yang-next discussion, I think we first
> > have
> > > > to
> > > > figure out how to evolve YANG without making waves in the current YANG
> > pond
> > > > and
> > > > let the operators and vendors do their work, without which YANG can
> > never
> > > > succeed.
> > > > 
> > > 
> > > IMO a new version of YANG would not be disruptive (if done right).
> > > The issue is whether it is cleaner in the long-run to introduce NBC
> > changes
> > > properly
> > > with a new version number, or not so properly, through YANG extensions.
> > 
> > I don't see much difference provided that the extensions will be properly
> > signalled. But we have to take into account that some tools that people use
> > may
> > not be updated for quite some time, and if they cannot properly work with
> > modules written for the new version (or extensions), then things will break.
> > 
> 
> So you want to work on YANG 1.2, but just the parts you want to change? ;-)

I am actually fine with not doing any changes to YANG 1.1 at all, except perhaps
bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would IMO be
immensely useful to rewrite the language specification and remove NETCONF- and
XML-specific part.

> There is no such thing as a critical extension in YANG 1.1.

One alternative to doing nothing is to introduce critical extensions but
temporarily forbid their use in IETF modules (so that existing tools continue to
work). This would allow for developing and testing new YANG features without
causing troubles to current YANG users. Specific areas and communities may
decide to treat some crictical extensions as required and use tools that support
them.

> IMO it would be a bad idea to develop standard modules that relied on tool
> support of
> any extension. A tool is allowed to skip any extension when parsing a module.
> This cannot be changed in YANG 1.1.
>  
> > This problem is actually not limited to YANG itself - people are reporting
> > problems with the transition to NMDA. 
> > 
> > > 
> > > E.g -- adding a leaf to the datastore that says "I don't follow the rules
> > in
> > > 7950"
> > > is still breaking the YANG 1.1 contract.  Using extensions instead of real
> > > statements
> > > is problematic because they are optional to implement (as you point out
> > all
> > > the time).
> > 
> > Yes, hence critical extensions. However, the problem is still the same -
> > these
> > changes require updated tools, and not all tools will be updated
> > immediately. I
> > think that we should make sure that (at least in the IETF) all modules will
> > be
> > compatible with tools supporting YANG 1.1, say for the next 5 years.
> > 
> 
> I am OK with the current WG priorities such as versioning.

Yes, work on versioning and packages should continue.

> Those YANG extensions simply clarify YANG 1.1 so no rules are broken
> and no YANG 1.1 functionality is removed if a tool ignores the extensions.
> Also OK with not working on YANG 1.2 or critical extensions.
> There are no must-have features at this time.

I agree.

Lada

> 
> > Lada
> > 
> 
> Andy
>  
> > > 
> > > Seems like the WG is going the YANG extension route, which has its own set
> > of
> > > problems
> > > compared to a new YANG language version.
> > > 
> > > 
> > > > Lada
> > > 
> > > Andy
> > >  
-- 
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] YANG next

[Andy Bierman]

On Tue, Jul 23, 2019 at 11:00 AM Ladislav Lhotka  wrote:

> On Tue, 2019-07-23 at 09:22 -0700, Andy Bierman wrote:
> >
> >
> > On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka  wrote:
> > > Hi,
> > >
> > > this morning I attended the side meeting "Next Step of IETF YANG". I
> was
> > > somewhat misled into thinking that it would be about future evolution
> of
> > > YANG
> > > the language, which was not the case at all. However, my personal
> conclusion
> > > from the meeting is that it would be a total disaster to throw in a new
> > > version
> > > of YANG within the next few years or so.
> > >
> >
> >
> > I hope a summary of the meeting is posted to the WG mailing list.
>
> I think so, minutes were taken.
>
> >
> > > The operators and equipment vendors are busy putting together YANG
> modules
> > > and
> > > tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> > > OpenConfig
> > > etc. A new YANG version (and modules written in it) would IMO be
> extremely
> > > counter-productive at this rather turbulent stage.
> > >
> > > So, if we want to continue the yang-next discussion, I think we first
> have
> > > to
> > > figure out how to evolve YANG without making waves in the current YANG
> pond
> > > and
> > > let the operators and vendors do their work, without which YANG can
> never
> > > succeed.
> > >
> >
> > IMO a new version of YANG would not be disruptive (if done right).
> > The issue is whether it is cleaner in the long-run to introduce NBC
> changes
> > properly
> > with a new version number, or not so properly, through YANG extensions.
>
> I don't see much difference provided that the extensions will be properly
> signalled. But we have to take into account that some tools that people
> use may
> not be updated for quite some time, and if they cannot properly work with
> modules written for the new version (or extensions), then things will
> break.
>
>
So you want to work on YANG 1.2, but just the parts you want to change? ;-)
There is no such thing as a critical extension in YANG 1.1.
IMO it would be a bad idea to develop standard modules that relied on tool
support of
any extension. A tool is allowed to skip any extension when parsing a
module.
This cannot be changed in YANG 1.1.


> This problem is actually not limited to YANG itself - people are reporting
> problems with the transition to NMDA.
>
> >
> > E.g -- adding a leaf to the datastore that says "I don't follow the
> rules in
> > 7950"
> > is still breaking the YANG 1.1 contract.  Using extensions instead of
> real
> > statements
> > is problematic because they are optional to implement (as you point out
> all
> > the time).
>
> Yes, hence critical extensions. However, the problem is still the same -
> these
> changes require updated tools, and not all tools will be updated
> immediately. I
> think that we should make sure that (at least in the IETF) all modules
> will be
> compatible with tools supporting YANG 1.1, say for the next 5 years.
>
>
I am OK with the current WG priorities such as versioning.
Those YANG extensions simply clarify YANG 1.1 so no rules are broken
and no YANG 1.1 functionality is removed if a tool ignores the extensions.
Also OK with not working on YANG 1.2 or critical extensions.
There are no must-have features at this time.

Lada
>
>
Andy


> >
> > Seems like the WG is going the YANG extension route, which has its own
> set of
> > problems
> > compared to a new YANG language version.
> >
> >
> > > Lada
> >
> > Andy
> >
> --
> 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] YANG next

[Juergen Schoenwaelder]

On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote:
> 
> This problem is actually not limited to YANG itself - people are reporting
> problems with the transition to NMDA. 
>

The YANG update from 1 to 1.1 mostly affected compiler writers - and
to a much lesser extend module authors and module implementors. NMDA,
affects client and server implementors much more directly, additional
instrumentation on the server side needs to be written, application
logic on the client side needs to be adjusted. NMDA is an evolution of
architectural principles and this already indicates that there is a
certain investment to make.

If we discuss YANG next, we should compare it to the YANG 1 to 1.1
transition and not to the NMDA transition. When we started YANG 1.1
work, there were people who said that nobody would implement it. But
then implementations were adopted relatively fast when we finalized
YANG 1.1.

While a collection of patches (updates) of YANG 1.1 may sound simpler,
I am not sure this is really true. We will loose a common baseline and
instead get complexity since we will get systems that all support
different sets of patches (updates) of YANG 1.1. I believe we are all
much better off if we have a common baseline language and tools that
support the common baseline language. Again, if done right, YANG next
will mostly affect compiler writers and tool makers and not so much
module authors and implementors.

/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] YANG next

[Ladislav Lhotka]

On Tue, 2019-07-23 at 19:14 +0100, Adrian Farrel wrote:
> > > I hope a summary of the meeting is posted to the WG mailing list.
> > 
> > I think so, minutes were taken.
> 
> I scribbled.
> So did Dan King.
> We sent our scribbles to Geng Liang and Qin Wu. 
> They will process.

Thanks for that.

> 
> It was a side meeting. 
> As Lou says, it was not part of any existing WG. Nor was it a BoF.
> 
> How and where and if the minutes are published is not a question for me to
> answer.
> 
> Adrian
> 
> PS I don't think this was a debate about creating a new version of the YANG
> language, and I don't think extensions or modifications to the YANG language
> were high on the list of "fixes" to the questions raised in the meeting.

Right, this is what I said in the beginning of my message.

Lada

> That doesn't mean that debate shouldn't/cannot happen, just that it is not
> (highly) relevant to the discussion at hand.
> 
> 
-- 
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] YANG next

[Adrian Farrel]

>> I hope a summary of the meeting is posted to the WG mailing list.
>
> I think so, minutes were taken.

I scribbled.
So did Dan King.
We sent our scribbles to Geng Liang and Qin Wu. 
They will process.

It was a side meeting. 
As Lou says, it was not part of any existing WG. Nor was it a BoF.

How and where and if the minutes are published is not a question for me to
answer.

Adrian

PS I don't think this was a debate about creating a new version of the YANG
language, and I don't think extensions or modifications to the YANG language
were high on the list of "fixes" to the questions raised in the meeting.
That doesn't mean that debate shouldn't/cannot happen, just that it is not
(highly) relevant to the discussion at hand.


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

Re: [netmod] YANG next

[Lou Berger]

On 7/23/2019 12:03 PM, Ladislav Lhotka wrote:

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled ...


This IETF's "side-meeting" approach to non-WG meetings is quite 
confusing.  This meeting was *not* a WG nor was it part of any NetMod WG 
coordinated activity.


Of course, any discussion on yang or other in-charter topics is always 
welcome on the list.


Lou

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

Re: [netmod] YANG next

[Ladislav Lhotka]

On Tue, 2019-07-23 at 09:22 -0700, Andy Bierman wrote:
> 
> 
> On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka  wrote:
> > Hi,
> > 
> > this morning I attended the side meeting "Next Step of IETF YANG". I was
> > somewhat misled into thinking that it would be about future evolution of
> > YANG
> > the language, which was not the case at all. However, my personal conclusion
> > from the meeting is that it would be a total disaster to throw in a new
> > version
> > of YANG within the next few years or so.
> > 
> 
> 
> I hope a summary of the meeting is posted to the WG mailing list.

I think so, minutes were taken.

>  
> > The operators and equipment vendors are busy putting together YANG modules
> > and
> > tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> > OpenConfig
> > etc. A new YANG version (and modules written in it) would IMO be extremely
> > counter-productive at this rather turbulent stage.
> > 
> > So, if we want to continue the yang-next discussion, I think we first have
> > to
> > figure out how to evolve YANG without making waves in the current YANG pond
> > and
> > let the operators and vendors do their work, without which YANG can never
> > succeed.
> > 
> 
> IMO a new version of YANG would not be disruptive (if done right).
> The issue is whether it is cleaner in the long-run to introduce NBC changes
> properly
> with a new version number, or not so properly, through YANG extensions.

I don't see much difference provided that the extensions will be properly
signalled. But we have to take into account that some tools that people use may
not be updated for quite some time, and if they cannot properly work with
modules written for the new version (or extensions), then things will break.

This problem is actually not limited to YANG itself - people are reporting
problems with the transition to NMDA. 

> 
> E.g -- adding a leaf to the datastore that says "I don't follow the rules in
> 7950"
> is still breaking the YANG 1.1 contract.  Using extensions instead of real
> statements
> is problematic because they are optional to implement (as you point out all
> the time).

Yes, hence critical extensions. However, the problem is still the same - these
changes require updated tools, and not all tools will be updated immediately. I
think that we should make sure that (at least in the IETF) all modules will be
compatible with tools supporting YANG 1.1, say for the next 5 years.

Lada

> 
> Seems like the WG is going the YANG extension route, which has its own set of
> problems
> compared to a new YANG language version.
> 
> 
> > Lada
> 
> Andy
>  
-- 
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] YANG next

[Ladislav Lhotka]

On Tue, 2019-07-23 at 16:22 +, Balázs Lengyel wrote:
> Hello,
> I share your concerns. However I see some ways of mitigating the problem:
> 1) Maybe the extension based solution is better than many people would
> believe. If we put new features (like status-information,
> import-revision-or-derived, preliminary-status etc.) into extensions e.g.
> Yang1-2:status-information older systems can just ignore them while never
> systems would still be able to use them. This might not work for all new
> functionality, but would definitely work for some.

This could work only for extensions that do not affect YANG semantics. For
example, if a server actively uses schema mount, then a client that ignores it
is next to useless.

For critical extensions that affect YANG semantics, it would IMO be necessary to
develop modules supporting them in separate branches, along with their 1.1-only
versions.

> 2) Some yang-next ideas are really clarifications of yang 1.1 (e.g. Clarify
> YANG "status" keyword usage (e.g., hierarchical)) so they will not disturb
> current users.

Of course, clarifications and bug fixes are OK.

Lada

> Regards Balazs
> 
> -Original Message-
> From: netmod  On Behalf Of Ladislav Lhotka
> Sent: 2019. július 23., kedd 12:03
> To: NETMOD WG 
> Subject: [netmod] YANG next
> 
> Hi,
> 
> this morning I attended the side meeting "Next Step of IETF YANG". I was
> somewhat misled into thinking that it would be about future evolution of
> YANG the language, which was not the case at all. However, my personal
> conclusion from the meeting is that it would be a total disaster to throw in
> a new version of YANG within the next few years or so.
> 
> The operators and equipment vendors are busy putting together YANG modules
> and tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> OpenConfig etc. A new YANG version (and modules written in it) would IMO be
> extremely counter-productive at this rather turbulent stage.
> 
> So, if we want to continue the yang-next discussion, I think we first have
> to figure out how to evolve YANG without making waves in the current YANG
> pond and let the operators and vendors do their work, without which YANG can
> never succeed.
> 
> Lada
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] YANG next

[Balázs Lengyel]

Hello,
I share your concerns. However I see some ways of mitigating the problem:
1) Maybe the extension based solution is better than many people would
believe. If we put new features (like status-information,
import-revision-or-derived, preliminary-status etc.) into extensions e.g.
Yang1-2:status-information older systems can just ignore them while never
systems would still be able to use them. This might not work for all new
functionality, but would definitely work for some.
2) Some yang-next ideas are really clarifications of yang 1.1 (e.g. Clarify
YANG "status" keyword usage (e.g., hierarchical)) so they will not disturb
current users.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Ladislav Lhotka
Sent: 2019. július 23., kedd 12:03
To: NETMOD WG 
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of
YANG the language, which was not the case at all. However, my personal
conclusion from the meeting is that it would be a total disaster to throw in
a new version of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules
and tools, filling the gaps, coping with NMDA, schema mount, IETF versus
OpenConfig etc. A new YANG version (and modules written in it) would IMO be
extremely counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have
to figure out how to evolve YANG without making waves in the current YANG
pond and let the operators and vendors do their work, without which YANG can
never succeed.

Lada

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

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG next

[Andy Bierman]

On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka  wrote:

> Hi,
>
> this morning I attended the side meeting "Next Step of IETF YANG". I was
> somewhat misled into thinking that it would be about future evolution of
> YANG
> the language, which was not the case at all. However, my personal
> conclusion
> from the meeting is that it would be a total disaster to throw in a new
> version
> of YANG within the next few years or so.
>
>

I hope a summary of the meeting is posted to the WG mailing list.


> The operators and equipment vendors are busy putting together YANG modules
> and
> tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> OpenConfig
> etc. A new YANG version (and modules written in it) would IMO be extremely
> counter-productive at this rather turbulent stage.
>
> So, if we want to continue the yang-next discussion, I think we first have
> to
> figure out how to evolve YANG without making waves in the current YANG
> pond and
> let the operators and vendors do their work, without which YANG can never
> succeed.
>
>
IMO a new version of YANG would not be disruptive (if done right).
The issue is whether it is cleaner in the long-run to introduce NBC changes
properly
with a new version number, or not so properly, through YANG extensions.

E.g -- adding a leaf to the datastore that says "I don't follow the rules
in 7950"
is still breaking the YANG 1.1 contract.  Using extensions instead of real
statements
is problematic because they are optional to implement (as you point out all
the time).

Seems like the WG is going the YANG extension route, which has its own set
of problems
compared to a new YANG language version.


Lada
>

Andy


>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> ___
> 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] YANG next

[Ladislav Lhotka]

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of YANG
the language, which was not the case at all. However, my personal conclusion
from the meeting is that it would be a total disaster to throw in a new version
of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules and
tools, filling the gaps, coping with NMDA, schema mount, IETF versus OpenConfig
etc. A new YANG version (and modules written in it) would IMO be extremely
counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have to
figure out how to evolve YANG without making waves in the current YANG pond and
let the operators and vendors do their work, without which YANG can never
succeed.

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] yang next issue #46 binary encoding support

[Kent Watsen]

Issue reopened and added to the "Further Discuss" column.

K.


> On Mar 31, 2019, at 6:32 AM, Rob Wilton (rwilton)  wrote:
> 
> I also agree that we should reopen this issue to further discuss any language 
> implications, and add it to the “Further Discuss” bucket.
>  
> I suggest that we just do this, unless someone objects.
>  
> Thanks,
> Rob
>  
>  
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Mahesh Jethanandani
> Sent: 29 March 2019 21:38
> To: Andy Bierman mailto:a...@yumaworks.com>>
> Cc: NetMod WG mailto:netmod@ietf.org>>
> Subject: Re: [netmod] yang next issue #46 binary encoding support
>  
> Based on this discussion, I think we should reopen and change the title of 
> this issue as “binary encoding in YANG support”, while I open a new issue in 
> netconf-next for “support for binary encoding in NETCONF”.
> 
> 
> On Mar 29, 2019, at 11:57 AM, Andy Bierman  <mailto:a...@yumaworks.com>> wrote:
>  
>  
> 
> On Fri, Mar 29, 2019 at 11:46 AM Juergen Schoenwaelder 
>  <mailto:j.schoenwael...@jacobs-university.de>> wrote:
> On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> > On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de 
> > <mailto:j.schoenwael...@jacobs-university.de>> wrote:
> > 
> > > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > > j.schoenwael...@jacobs-university.de 
> > > > <mailto:j.schoenwael...@jacobs-university.de>> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > this is issue is closed but I wonder whether this is correct. I have
> > > > > several questions looking at the issue on github:
> > > > >
> > > > > - Why is this not a YANG issue?
> > > > > - Which workaround is better?
> > > > > - Why is this tagged as a NETCONF issue?
> > > > >
> > > > >
> > > > Did you mean this should be NETCONF issue?
> > > > It is more of a protocol problem then a modeling problem.
> > > > The goal is to use the model unaltered.
> > >
> > > I think it would be valuable if say the definition of ipv4-address
> > > could state that a canonical binary representation is of type binary {
> > > length 4; }. Doing this is only meaningful for some types but it would
> > > allow to add more binary representations over time.
> > >
> > > > > If we want to support binary encodings, we need to allow modelers to
> > > > > define which types map to a canonical binary representation in
> > > > > addition to the canonical string representation. As stated in the
> > > > > issue description, hard-wiring some types in the encoding
> > > > > specifications is very limited.
> > > > >
> > > > > In terms of backwards compatibility, this issue should IMHO be tagged
> > > > > high (adding binary encoding for some types does not cause any
> > > > > backwards compatibility problem since so far we have only strings).
> > > > >
> > > > >
> > > > Not so sure.
> > > > The base64 encoding could look like a valid string.
> > > > The receiver must know a binary type is being sent (XML and JSON both
> > > fail
> > > > here, but not CBOR).
> > >
> > > I am talking about CBOR, not about XML or JSON. I want to provide
> > > hints to CBOR (or similar binary encodings) that values can be
> > > represented in a different format. I do not expect these hints to be
> > > used by XML or JSON. If you need binary encoding efficiency, use CBOR
> > > instead of JSON.
> > >
> > > > > While I do not have a solution proposal, I think this issue is worth
> > > > > to look at and we should not close it right now.
> > > > >
> > > > >
> > > > I have a solution proposal, but I have not implemented it yet, so it it
> > > not
> > > > detailed...
> > > >
> > > > Both sender and receiver need to agree on the binary encoding and how 
> > > > the
> > > > data is tagged as binary.
> > > >
> > > > This expired draft should address that problem:
> > > > https://tools.ietf..org/html/draft-mahesh-netconf-binary-encoding-01 
> > > > <https://tools.ietf.org/html

Re: [netmod] yang next issue #46 binary encoding support

[Rob Wilton (rwilton)]

I also agree that we should reopen this issue to further discuss any language 
implications, and add it to the “Further Discuss” bucket.

I suggest that we just do this, unless someone objects.

Thanks,
Rob


From: netmod  On Behalf Of Mahesh Jethanandani
Sent: 29 March 2019 21:38
To: Andy Bierman 
Cc: NetMod WG 
Subject: Re: [netmod] yang next issue #46 binary encoding support

Based on this discussion, I think we should reopen and change the title of this 
issue as “binary encoding in YANG support”, while I open a new issue in 
netconf-next for “support for binary encoding in NETCONF”.


On Mar 29, 2019, at 11:57 AM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:


On Fri, Mar 29, 2019 at 11:46 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>
>  wrote:
>
> > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>
> > >  wrote:
> > >
> > > > Hi,
> > > >
> > > > this is issue is closed but I wonder whether this is correct. I have
> > > > several questions looking at the issue on github:
> > > >
> > > > - Why is this not a YANG issue?
> > > > - Which workaround is better?
> > > > - Why is this tagged as a NETCONF issue?
> > > >
> > > >
> > > Did you mean this should be NETCONF issue?
> > > It is more of a protocol problem then a modeling problem.
> > > The goal is to use the model unaltered.
> >
> > I think it would be valuable if say the definition of ipv4-address
> > could state that a canonical binary representation is of type binary {
> > length 4; }. Doing this is only meaningful for some types but it would
> > allow to add more binary representations over time.
> >
> > > > If we want to support binary encodings, we need to allow modelers to
> > > > define which types map to a canonical binary representation in
> > > > addition to the canonical string representation. As stated in the
> > > > issue description, hard-wiring some types in the encoding
> > > > specifications is very limited.
> > > >
> > > > In terms of backwards compatibility, this issue should IMHO be tagged
> > > > high (adding binary encoding for some types does not cause any
> > > > backwards compatibility problem since so far we have only strings).
> > > >
> > > >
> > > Not so sure.
> > > The base64 encoding could look like a valid string.
> > > The receiver must know a binary type is being sent (XML and JSON both
> > fail
> > > here, but not CBOR).
> >
> > I am talking about CBOR, not about XML or JSON. I want to provide
> > hints to CBOR (or similar binary encodings) that values can be
> > represented in a different format. I do not expect these hints to be
> > used by XML or JSON. If you need binary encoding efficiency, use CBOR
> > instead of JSON.
> >
> > > > While I do not have a solution proposal, I think this issue is worth
> > > > to look at and we should not close it right now.
> > > >
> > > >
> > > I have a solution proposal, but I have not implemented it yet, so it it
> > not
> > > detailed...
> > >
> > > Both sender and receiver need to agree on the binary encoding and how the
> > > data is tagged as binary.
> > >
> > > This expired draft should address that problem:
> > > https://tools.ietf..org/html/draft-mahesh-netconf-binary-encoding-01<https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01>
> > >
> > > For every type T that they agree on, there are standard T.b2y() and
> > T.y2b()
> > > conversion functions.
> > > There are also some extensions to define conversion templates so vendors
> > > can add their own types.
> > >
> > > The YANG modules do not need to actually be altered.  The peers will
> > > negotiate the
> > > set of types that will be sent as binary when the session starts.
> > > The receiver knows T and the SID for each object, and will accept either
> > > the YANG or binary encoding.
> >
> > Sounds complex for me to negotiate this. I rather say once that a
> > binary enco

Re: [netmod] yang next issue #46 binary encoding support

[Mahesh Jethanandani]

Based on this discussion, I think we should reopen and change the title of this 
issue as “binary encoding in YANG support”, while I open a new issue in 
netconf-next for “support for binary encoding in NETCONF”.

> On Mar 29, 2019, at 11:57 AM, Andy Bierman  wrote:
> 
> 
> 
> On Fri, Mar 29, 2019 at 11:46 AM Juergen Schoenwaelder 
>  > wrote:
> On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> > On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de 
> > > wrote:
> > 
> > > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > > j.schoenwael...@jacobs-university.de 
> > > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > this is issue is closed but I wonder whether this is correct. I have
> > > > > several questions looking at the issue on github:
> > > > >
> > > > > - Why is this not a YANG issue?
> > > > > - Which workaround is better?
> > > > > - Why is this tagged as a NETCONF issue?
> > > > >
> > > > >
> > > > Did you mean this should be NETCONF issue?
> > > > It is more of a protocol problem then a modeling problem.
> > > > The goal is to use the model unaltered.
> > >
> > > I think it would be valuable if say the definition of ipv4-address
> > > could state that a canonical binary representation is of type binary {
> > > length 4; }. Doing this is only meaningful for some types but it would
> > > allow to add more binary representations over time.
> > >
> > > > > If we want to support binary encodings, we need to allow modelers to
> > > > > define which types map to a canonical binary representation in
> > > > > addition to the canonical string representation. As stated in the
> > > > > issue description, hard-wiring some types in the encoding
> > > > > specifications is very limited.
> > > > >
> > > > > In terms of backwards compatibility, this issue should IMHO be tagged
> > > > > high (adding binary encoding for some types does not cause any
> > > > > backwards compatibility problem since so far we have only strings).
> > > > >
> > > > >
> > > > Not so sure.
> > > > The base64 encoding could look like a valid string.
> > > > The receiver must know a binary type is being sent (XML and JSON both
> > > fail
> > > > here, but not CBOR).
> > >
> > > I am talking about CBOR, not about XML or JSON. I want to provide
> > > hints to CBOR (or similar binary encodings) that values can be
> > > represented in a different format. I do not expect these hints to be
> > > used by XML or JSON. If you need binary encoding efficiency, use CBOR
> > > instead of JSON.
> > >
> > > > > While I do not have a solution proposal, I think this issue is worth
> > > > > to look at and we should not close it right now.
> > > > >
> > > > >
> > > > I have a solution proposal, but I have not implemented it yet, so it it
> > > not
> > > > detailed...
> > > >
> > > > Both sender and receiver need to agree on the binary encoding and how 
> > > > the
> > > > data is tagged as binary.
> > > >
> > > > This expired draft should address that problem:
> > > > https://tools.ietf..org/html/draft-mahesh-netconf-binary-encoding-01 
> > > > 
> > > >
> > > > For every type T that they agree on, there are standard T.b2y() and
> > > T.y2b()
> > > > conversion functions.
> > > > There are also some extensions to define conversion templates so vendors
> > > > can add their own types.
> > > >
> > > > The YANG modules do not need to actually be altered.  The peers will
> > > > negotiate the
> > > > set of types that will be sent as binary when the session starts.
> > > > The receiver knows T and the SID for each object, and will accept either
> > > > the YANG or binary encoding.
> > >
> > > Sounds complex for me to negotiate this. I rather say once that a
> > > binary encoding can ship an IPv6 address as type binary { length 16; }
> > > and then CBOR will simply do the right thing.
> > >
> > >
> > OK, but this would require new type names.
> > You cannot simply change some standard type to be a union with a binary
> > type.
> >
> > This forces all implementations of that type to support the binary variant.
> > That breaks old clients that worked with the version before the binary
> > variant.
> > 
> > The ripple effect on the models changing types would be non-trivial.
> > Using this union-type approach forces every protocol to support the binary
> > encoding,
> > yet base64 in a union with strings is very error-prone.
> > 
> 
> I am not proposing do change the type definitions we have. My idea was
> to have an optional additional definition for binary encodings. Here
> is an ad-hoc example (I do not like the details of the syntax, but
> perhaps this helps to understand the idea):
> 
>  typedef ipv4-address {

Re: [netmod] yang next issue #46 binary encoding support

[Andy Bierman]

On Fri, Mar 29, 2019 at 11:46 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> > On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > > j.schoenwael...@jacobs-university.de> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > this is issue is closed but I wonder whether this is correct. I
> have
> > > > > several questions looking at the issue on github:
> > > > >
> > > > > - Why is this not a YANG issue?
> > > > > - Which workaround is better?
> > > > > - Why is this tagged as a NETCONF issue?
> > > > >
> > > > >
> > > > Did you mean this should be NETCONF issue?
> > > > It is more of a protocol problem then a modeling problem.
> > > > The goal is to use the model unaltered.
> > >
> > > I think it would be valuable if say the definition of ipv4-address
> > > could state that a canonical binary representation is of type binary {
> > > length 4; }. Doing this is only meaningful for some types but it would
> > > allow to add more binary representations over time.
> > >
> > > > > If we want to support binary encodings, we need to allow modelers
> to
> > > > > define which types map to a canonical binary representation in
> > > > > addition to the canonical string representation. As stated in the
> > > > > issue description, hard-wiring some types in the encoding
> > > > > specifications is very limited.
> > > > >
> > > > > In terms of backwards compatibility, this issue should IMHO be
> tagged
> > > > > high (adding binary encoding for some types does not cause any
> > > > > backwards compatibility problem since so far we have only strings).
> > > > >
> > > > >
> > > > Not so sure.
> > > > The base64 encoding could look like a valid string.
> > > > The receiver must know a binary type is being sent (XML and JSON both
> > > fail
> > > > here, but not CBOR).
> > >
> > > I am talking about CBOR, not about XML or JSON. I want to provide
> > > hints to CBOR (or similar binary encodings) that values can be
> > > represented in a different format. I do not expect these hints to be
> > > used by XML or JSON. If you need binary encoding efficiency, use CBOR
> > > instead of JSON.
> > >
> > > > > While I do not have a solution proposal, I think this issue is
> worth
> > > > > to look at and we should not close it right now.
> > > > >
> > > > >
> > > > I have a solution proposal, but I have not implemented it yet, so it
> it
> > > not
> > > > detailed...
> > > >
> > > > Both sender and receiver need to agree on the binary encoding and
> how the
> > > > data is tagged as binary.
> > > >
> > > > This expired draft should address that problem:
> > > > https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> > > >
> > > > For every type T that they agree on, there are standard T.b2y() and
> > > T.y2b()
> > > > conversion functions.
> > > > There are also some extensions to define conversion templates so
> vendors
> > > > can add their own types.
> > > >
> > > > The YANG modules do not need to actually be altered.  The peers will
> > > > negotiate the
> > > > set of types that will be sent as binary when the session starts.
> > > > The receiver knows T and the SID for each object, and will accept
> either
> > > > the YANG or binary encoding.
> > >
> > > Sounds complex for me to negotiate this. I rather say once that a
> > > binary encoding can ship an IPv6 address as type binary { length 16; }
> > > and then CBOR will simply do the right thing.
> > >
> > >
> > OK, but this would require new type names.
> > You cannot simply change some standard type to be a union with a binary
> > type.
> >
> > This forces all implementations of that type to support the binary
> variant.
> > That breaks old clients that worked with the version before the binary
> > variant.
> >
> > The ripple effect on the models changing types would be non-trivial.
> > Using this union-type approach forces every protocol to support the
> binary
> > encoding,
> > yet base64 in a union with strings is very error-prone.
> >
>
> I am not proposing do change the type definitions we have. My idea was
> to have an optional additional definition for binary encodings. Here
> is an ad-hoc example (I do not like the details of the syntax, but
> perhaps this helps to understand the idea):
>
>  typedef ipv4-address {
>type string {
>  pattern
>'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>  +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
>}
>description
>  "The ipv4-address type represents an IPv4 address in
>   dotted-quad notation.";
>
>binary-representation {
>  type binary {
>length 4;
>  }
>  description
>"The binary 

Re: [netmod] yang next issue #46 binary encoding support

[Juergen Schoenwaelder]

On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > j.schoenwael...@jacobs-university.de> wrote:
> > >
> > > > Hi,
> > > >
> > > > this is issue is closed but I wonder whether this is correct. I have
> > > > several questions looking at the issue on github:
> > > >
> > > > - Why is this not a YANG issue?
> > > > - Which workaround is better?
> > > > - Why is this tagged as a NETCONF issue?
> > > >
> > > >
> > > Did you mean this should be NETCONF issue?
> > > It is more of a protocol problem then a modeling problem.
> > > The goal is to use the model unaltered.
> >
> > I think it would be valuable if say the definition of ipv4-address
> > could state that a canonical binary representation is of type binary {
> > length 4; }. Doing this is only meaningful for some types but it would
> > allow to add more binary representations over time.
> >
> > > > If we want to support binary encodings, we need to allow modelers to
> > > > define which types map to a canonical binary representation in
> > > > addition to the canonical string representation. As stated in the
> > > > issue description, hard-wiring some types in the encoding
> > > > specifications is very limited.
> > > >
> > > > In terms of backwards compatibility, this issue should IMHO be tagged
> > > > high (adding binary encoding for some types does not cause any
> > > > backwards compatibility problem since so far we have only strings).
> > > >
> > > >
> > > Not so sure.
> > > The base64 encoding could look like a valid string.
> > > The receiver must know a binary type is being sent (XML and JSON both
> > fail
> > > here, but not CBOR).
> >
> > I am talking about CBOR, not about XML or JSON. I want to provide
> > hints to CBOR (or similar binary encodings) that values can be
> > represented in a different format. I do not expect these hints to be
> > used by XML or JSON. If you need binary encoding efficiency, use CBOR
> > instead of JSON.
> >
> > > > While I do not have a solution proposal, I think this issue is worth
> > > > to look at and we should not close it right now.
> > > >
> > > >
> > > I have a solution proposal, but I have not implemented it yet, so it it
> > not
> > > detailed...
> > >
> > > Both sender and receiver need to agree on the binary encoding and how the
> > > data is tagged as binary.
> > >
> > > This expired draft should address that problem:
> > > https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> > >
> > > For every type T that they agree on, there are standard T.b2y() and
> > T.y2b()
> > > conversion functions.
> > > There are also some extensions to define conversion templates so vendors
> > > can add their own types.
> > >
> > > The YANG modules do not need to actually be altered.  The peers will
> > > negotiate the
> > > set of types that will be sent as binary when the session starts.
> > > The receiver knows T and the SID for each object, and will accept either
> > > the YANG or binary encoding.
> >
> > Sounds complex for me to negotiate this. I rather say once that a
> > binary encoding can ship an IPv6 address as type binary { length 16; }
> > and then CBOR will simply do the right thing.
> >
> >
> OK, but this would require new type names.
> You cannot simply change some standard type to be a union with a binary
> type.
>
> This forces all implementations of that type to support the binary variant.
> That breaks old clients that worked with the version before the binary
> variant.
> 
> The ripple effect on the models changing types would be non-trivial.
> Using this union-type approach forces every protocol to support the binary
> encoding,
> yet base64 in a union with strings is very error-prone.
> 

I am not proposing do change the type definitions we have. My idea was
to have an optional additional definition for binary encodings. Here
is an ad-hoc example (I do not like the details of the syntax, but
perhaps this helps to understand the idea):

 typedef ipv4-address {
   type string {
 pattern
   '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
 +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
   }
   description
 "The ipv4-address type represents an IPv4 address in
  dotted-quad notation.";

   binary-representation {
 type binary {
   length 4;
 }
 description
   "The binary representation uses as 4-byte binary string
in network byte ordering.";
   }
 }

The CBOR encoder (or other binary encoders) would then encode the
value as a 4 byte binary value, the XML and JSON encoder would use the
canonical string representation.  If the binary-representation is not
specified, then the generic CBOR encoding rules 

Re: [netmod] yang next issue #46 binary encoding support

[Andy Bierman]

On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > Hi,
> > >
> > > this is issue is closed but I wonder whether this is correct. I have
> > > several questions looking at the issue on github:
> > >
> > > - Why is this not a YANG issue?
> > > - Which workaround is better?
> > > - Why is this tagged as a NETCONF issue?
> > >
> > >
> > Did you mean this should be NETCONF issue?
> > It is more of a protocol problem then a modeling problem.
> > The goal is to use the model unaltered.
>
> I think it would be valuable if say the definition of ipv4-address
> could state that a canonical binary representation is of type binary {
> length 4; }. Doing this is only meaningful for some types but it would
> allow to add more binary representations over time.
>
> > > If we want to support binary encodings, we need to allow modelers to
> > > define which types map to a canonical binary representation in
> > > addition to the canonical string representation. As stated in the
> > > issue description, hard-wiring some types in the encoding
> > > specifications is very limited.
> > >
> > > In terms of backwards compatibility, this issue should IMHO be tagged
> > > high (adding binary encoding for some types does not cause any
> > > backwards compatibility problem since so far we have only strings).
> > >
> > >
> > Not so sure.
> > The base64 encoding could look like a valid string.
> > The receiver must know a binary type is being sent (XML and JSON both
> fail
> > here, but not CBOR).
>
> I am talking about CBOR, not about XML or JSON. I want to provide
> hints to CBOR (or similar binary encodings) that values can be
> represented in a different format. I do not expect these hints to be
> used by XML or JSON. If you need binary encoding efficiency, use CBOR
> instead of JSON.
>
> > > While I do not have a solution proposal, I think this issue is worth
> > > to look at and we should not close it right now.
> > >
> > >
> > I have a solution proposal, but I have not implemented it yet, so it it
> not
> > detailed...
> >
> > Both sender and receiver need to agree on the binary encoding and how the
> > data is tagged as binary.
> >
> > This expired draft should address that problem:
> > https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> >
> > For every type T that they agree on, there are standard T.b2y() and
> T.y2b()
> > conversion functions.
> > There are also some extensions to define conversion templates so vendors
> > can add their own types.
> >
> > The YANG modules do not need to actually be altered.  The peers will
> > negotiate the
> > set of types that will be sent as binary when the session starts.
> > The receiver knows T and the SID for each object, and will accept either
> > the YANG or binary encoding.
>
> Sounds complex for me to negotiate this. I rather say once that a
> binary encoding can ship an IPv6 address as type binary { length 16; }
> and then CBOR will simply do the right thing.
>
>
OK, but this would require new type names.
You cannot simply change some standard type to be a union with a binary
type.
This forces all implementations of that type to support the binary variant.
That breaks old clients that worked with the version before the binary
variant.

The ripple effect on the models changing types would be non-trivial.
Using this union-type approach forces every protocol to support the binary
encoding,
yet base64 in a union with strings is very error-prone.


/js
>

Andy



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

Re: [netmod] yang next issue #46 binary encoding support

[Juergen Schoenwaelder]

On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > Hi,
> >
> > this is issue is closed but I wonder whether this is correct. I have
> > several questions looking at the issue on github:
> >
> > - Why is this not a YANG issue?
> > - Which workaround is better?
> > - Why is this tagged as a NETCONF issue?
> >
> >
> Did you mean this should be NETCONF issue?
> It is more of a protocol problem then a modeling problem.
> The goal is to use the model unaltered.
 
I think it would be valuable if say the definition of ipv4-address
could state that a canonical binary representation is of type binary {
length 4; }. Doing this is only meaningful for some types but it would
allow to add more binary representations over time.
 
> > If we want to support binary encodings, we need to allow modelers to
> > define which types map to a canonical binary representation in
> > addition to the canonical string representation. As stated in the
> > issue description, hard-wiring some types in the encoding
> > specifications is very limited.
> >
> > In terms of backwards compatibility, this issue should IMHO be tagged
> > high (adding binary encoding for some types does not cause any
> > backwards compatibility problem since so far we have only strings).
> >
> >
> Not so sure.
> The base64 encoding could look like a valid string.
> The receiver must know a binary type is being sent (XML and JSON both fail
> here, but not CBOR).

I am talking about CBOR, not about XML or JSON. I want to provide
hints to CBOR (or similar binary encodings) that values can be
represented in a different format. I do not expect these hints to be
used by XML or JSON. If you need binary encoding efficiency, use CBOR
instead of JSON.

> > While I do not have a solution proposal, I think this issue is worth
> > to look at and we should not close it right now.
> >
> >
> I have a solution proposal, but I have not implemented it yet, so it it not
> detailed...
> 
> Both sender and receiver need to agree on the binary encoding and how the
> data is tagged as binary.
> 
> This expired draft should address that problem:
> https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> 
> For every type T that they agree on, there are standard T.b2y() and T.y2b()
> conversion functions.
> There are also some extensions to define conversion templates so vendors
> can add their own types.
>
> The YANG modules do not need to actually be altered.  The peers will
> negotiate the
> set of types that will be sent as binary when the session starts.
> The receiver knows T and the SID for each object, and will accept either
> the YANG or binary encoding.

Sounds complex for me to negotiate this. I rather say once that a
binary encoding can ship an IPv6 address as type binary { length 16; }
and then CBOR will simply do the right thing.

/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] yang next issue #46 binary encoding support

[Andy Bierman]

On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> Hi,
>
> this is issue is closed but I wonder whether this is correct. I have
> several questions looking at the issue on github:
>
> - Why is this not a YANG issue?
> - Which workaround is better?
> - Why is this tagged as a NETCONF issue?
>
>
Did you mean this should be NETCONF issue?
It is more of a protocol problem then a modeling problem.
The goal is to use the model unaltered.



> If we want to support binary encodings, we need to allow modelers to
> define which types map to a canonical binary representation in
> addition to the canonical string representation. As stated in the
> issue description, hard-wiring some types in the encoding
> specifications is very limited.
>
> In terms of backwards compatibility, this issue should IMHO be tagged
> high (adding binary encoding for some types does not cause any
> backwards compatibility problem since so far we have only strings).
>
>
Not so sure.
The base64 encoding could look like a valid string.
The receiver must know a binary type is being sent (XML and JSON both fail
here, but not CBOR).



> While I do not have a solution proposal, I think this issue is worth
> to look at and we should not close it right now.
>
>
I have a solution proposal, but I have not implemented it yet, so it it not
detailed...

Both sender and receiver need to agree on the binary encoding and how the
data is tagged as binary.

This expired draft should address that problem:
https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01

For every type T that they agree on, there are standard T.b2y() and T.y2b()
conversion functions.
There are also some extensions to define conversion templates so vendors
can add their own types.

The YANG modules do not need to actually be altered.  The peers will
negotiate the
set of types that will be sent as binary when the session starts.
The receiver knows T and the SID for each object, and will accept either
the YANG or binary encoding.



> /js
>
>
Andy


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

[netmod] yang next issue #46 binary encoding support

[Juergen Schoenwaelder]

Hi,

this is issue is closed but I wonder whether this is correct. I have
several questions looking at the issue on github:

- Why is this not a YANG issue?
- Which workaround is better?
- Why is this tagged as a NETCONF issue?

If we want to support binary encodings, we need to allow modelers to
define which types map to a canonical binary representation in
addition to the canonical string representation. As stated in the
issue description, hard-wiring some types in the encoding
specifications is very limited.

In terms of backwards compatibility, this issue should IMHO be tagged
high (adding binary encoding for some types does not cause any
backwards compatibility problem since so far we have only strings).

While I do not have a solution proposal, I think this issue is worth
to look at and we should not close it right now.

/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] YANG-next Selection Discussion in Prague

[Kent Watsen]

For those interested in the YANG-next, there are three upcoming events:

1) a 2-hour virtual interim on Mar 20 (the IESG-Secretary will send out the 
invite shortly)
2) a 10-15 minute presentation on Monday, Mar 25 in NETMOD session #1
3) a 2-hour deep-dive meeting on Wednesday, Mar 27 (details below)


YANG-next Deep Dive Meeting:
--
Wednesday, Mar 27, 15:00-17:00 in Karlin 3 (link to map [1])
Occupancy: up to 60 attendees 
Configuration: theater 
Projector: yes

[1] https://datatracker.ietf.org/meeting/104/floor-plan?room=karlin-3#mezzanine


Kent // as co-chair


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

Re: [netmod] yang-next meeting at IETF 104?

[Reshad Rahman (rrahman)]

I am interested in attending the virtual meeting(s) and the in-person meeting 
in Prague (Monday-Thursday preferably).

On 2019-01-14, 5:27 PM, "netmod on behalf of Kent Watsen" 
 wrote:

>> PS: I've been too busy to setup a virtual meeting for us to finish the
>> review of the YANG-next items in the GitHub tracker.  But things are
>> just beginning to free up a little for me now.  Would folks like to
>> have a meeting before 104 to finish that review?
>
> I think that's what the side meeting would do - review the current
> items to see what makes sense.

Sure, but perhaps the in-person time would be better spent analyzing the 
results of the reviews?  Recall that we're trying to score each item on three 
axis: importance, complexity, backward-compatibility.

Current results here:  
https://github.com/netmod-wg/yang-next/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc.

At the rate we were going (about 40% done), I imagine it taking 2-4 hours 
to score the remaining issues.  This may not be an issue if we can meet 
multiple times during the week but, if time is tight, I'd rather have this part 
done before we meet.

Kent // contributor


___
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-next meeting at IETF 104?

[Ladislav Lhotka]

On Mon, 2019-01-14 at 09:07 -0800, Andy Bierman wrote:
> Hi,
> 
> Is there any interest in 1 or more side meetings at the next IETF to
> discuss the yang-next issue list, towards the goal of determining the
> problem space in scope for YANG 1.2?

Yes, I would be interested. I have no preferences in terms of timing.

Lada

> 
> Those of us who would need to make travel plans would appreciate it
> if meetings like this were scheduled ASAP instead of ALAP ;-)
> 
> 
> Andy
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] yang-next meeting at IETF 104?

[Andy Bierman]

On Mon, Jan 14, 2019 at 2:27 PM Kent Watsen  wrote:

> >> PS: I've been too busy to setup a virtual meeting for us to finish the
> >> review of the YANG-next items in the GitHub tracker.  But things are
> >> just beginning to free up a little for me now.  Would folks like to
> >> have a meeting before 104 to finish that review?
> >
> > I think that's what the side meeting would do - review the current
> > items to see what makes sense.
>
> Sure, but perhaps the in-person time would be better spent analyzing the
> results of the reviews?  Recall that we're trying to score each item on
> three axis: importance, complexity, backward-compatibility.
>
>
I agree with this approach.  It is too easy to get
bogged down on how a solution might work (or worse, let's compare
2 or 3 different solutions right now) and never finish the issue list.

There are spot solutions in progress (e.g., on-change
notification,  yang-data)
that might be much better handled with robust generalized solutions in YANG.
I have some concern that a patchwork of optional extensions is worse for
end-users
in the long-term, than a new YANG language version.


Current results here:
> https://github.com/netmod-wg/yang-next/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
> .
>
> At the rate we were going (about 40% done), I imagine it taking 2-4 hours
> to score the remaining issues.  This may not be an issue if we can meet
> multiple times during the week but, if time is tight, I'd rather have this
> part done before we meet.
>
> Kent // contributor
>
>
>

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

Re: [netmod] yang-next meeting at IETF 104?

[Kent Watsen]

>> PS: I've been too busy to setup a virtual meeting for us to finish the
>> review of the YANG-next items in the GitHub tracker.  But things are
>> just beginning to free up a little for me now.  Would folks like to
>> have a meeting before 104 to finish that review?
>
> I think that's what the side meeting would do - review the current
> items to see what makes sense.

Sure, but perhaps the in-person time would be better spent analyzing the 
results of the reviews?  Recall that we're trying to score each item on three 
axis: importance, complexity, backward-compatibility.

Current results here:  
https://github.com/netmod-wg/yang-next/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc.

At the rate we were going (about 40% done), I imagine it taking 2-4 hours to 
score the remaining issues.  This may not be an issue if we can meet multiple 
times during the week but, if time is tight, I'd rather have this part done 
before we meet.

Kent // contributor


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

Re: [netmod] yang-next meeting at IETF 104?

[Martin Bjorklund]

Kent Watsen  wrote:
> I'm interested as well.
> 
> PS: I've been too busy to setup a virtual meeting for us to finish the
> review of the YANG-next items in the GitHub tracker.  But things are
> just beginning to free up a little for me now.  Would folks like to
> have a meeting before 104 to finish that review?

I think that's what the side meeting would do - review the current
items to see what makes sense.


/martin



> 
> Kent // contributor
> 
> 
> -Original Message-
> From: netmod  on behalf of Robert Wilton
> 
> Date: Monday, January 14, 2019 at 12:19 PM
> To: Martin Bjorklund , "a...@yumaworks.com"
> 
> Cc: NETMOD Working Group 
> Subject: Re: [netmod] yang-next meeting at IETF 104?
> 
> I would also be interested.  During the week would also be
> best. Friday
> morning could also be a possibility depending on whether there are 
> sessions scheduled.
> 
> Thanks,
> Rob
> 
> 
> On 14/01/2019 17:10, Martin Bjorklund wrote:
> > Hi,
> >
> > Andy Bierman  wrote:
> >> Hi,
> >>
> >> Is there any interest in 1 or more side meetings at the next IETF to
> >> discuss the yang-next issue list, towards the goal of determining the
> >> problem space in scope for YANG 1.2?
> > I am interested in this.  I prefer a meeting during the week; my plan
> > is to arrive Sunday afternoon.
> >
> >
> > /martin
> >
> >> Those of us who would need to make travel plans would appreciate it
> >> if meetings like this were scheduled ASAP instead of ALAP ;-)
> >>
> >>
> >> Andy
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=BfGnjYejrGjQ93xAzY1pzA9M9wXXY7rNFeWy3dKZXWc=fNOa2UIOMhNDcO3nFEFBdqQSdrQ-KaYNF2GaTgfRsgI=
> > .
> >
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=BfGnjYejrGjQ93xAzY1pzA9M9wXXY7rNFeWy3dKZXWc=fNOa2UIOMhNDcO3nFEFBdqQSdrQ-KaYNF2GaTgfRsgI=
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-next meeting at IETF 104?

[Mahesh Jethanandani]

Hi Kent,

I think it makes sense to have a virtual meeting before 104. 

Mahesh Jethanandani
mjethanand...@gmail.com

> On Jan 15, 2019, at 6:45 AM, Kent Watsen  wrote:
> 
> I'm interested as well.
> 
> PS: I've been too busy to setup a virtual meeting for us to finish the review 
> of the YANG-next items in the GitHub tracker.  But things are just beginning 
> to free up a little for me now.  Would folks like to have a meeting before 
> 104 to finish that review?
> 
> Kent // contributor
> 
> 
> -Original Message-
> From: netmod  on behalf of Robert Wilton 
> 
> Date: Monday, January 14, 2019 at 12:19 PM
> To: Martin Bjorklund , "a...@yumaworks.com" 
> 
> Cc: NETMOD Working Group 
> Subject: Re: [netmod] yang-next meeting at IETF 104?
> 
> I would also be interested.  During the week would also be best. Friday 
> morning could also be a possibility depending on whether there are 
> sessions scheduled.
> 
> Thanks,
> Rob
> 
> 
>> On 14/01/2019 17:10, Martin Bjorklund wrote:
>> Hi,
>> 
>> Andy Bierman  wrote:
>>> Hi,
>>> 
>>> Is there any interest in 1 or more side meetings at the next IETF to
>>> discuss the yang-next issue list, towards the goal of determining the
>>> problem space in scope for YANG 1.2?
>> I am interested in this.  I prefer a meeting during the week; my plan
>> is to arrive Sunday afternoon.
>> 
>> 
>> /martin
>> 
>>> Those of us who would need to make travel plans would appreciate it
>>> if meetings like this were scheduled ASAP instead of ALAP ;-)
>>> 
>>> 
>>> Andy
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=BfGnjYejrGjQ93xAzY1pzA9M9wXXY7rNFeWy3dKZXWc=fNOa2UIOMhNDcO3nFEFBdqQSdrQ-KaYNF2GaTgfRsgI=
>> .
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=BfGnjYejrGjQ93xAzY1pzA9M9wXXY7rNFeWy3dKZXWc=fNOa2UIOMhNDcO3nFEFBdqQSdrQ-KaYNF2GaTgfRsgI=
> 
> ___
> 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-next meeting at IETF 104?

[Kent Watsen]

I'm interested as well.

PS: I've been too busy to setup a virtual meeting for us to finish the review 
of the YANG-next items in the GitHub tracker.  But things are just beginning to 
free up a little for me now.  Would folks like to have a meeting before 104 to 
finish that review?

Kent // contributor


-Original Message-
From: netmod  on behalf of Robert Wilton 

Date: Monday, January 14, 2019 at 12:19 PM
To: Martin Bjorklund , "a...@yumaworks.com" 

Cc: NETMOD Working Group 
Subject: Re: [netmod] yang-next meeting at IETF 104?

I would also be interested.  During the week would also be best. Friday 
morning could also be a possibility depending on whether there are 
sessions scheduled.

Thanks,
Rob


On 14/01/2019 17:10, Martin Bjorklund wrote:
> Hi,
>
> Andy Bierman  wrote:
>> Hi,
>>
>> Is there any interest in 1 or more side meetings at the next IETF to
>> discuss the yang-next issue list, towards the goal of determining the
>> problem space in scope for YANG 1.2?
> I am interested in this.  I prefer a meeting during the week; my plan
> is to arrive Sunday afternoon.
>
>
> /martin
>
>> Those of us who would need to make travel plans would appreciate it
>> if meetings like this were scheduled ASAP instead of ALAP ;-)
>>
>>
>> Andy
> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=BfGnjYejrGjQ93xAzY1pzA9M9wXXY7rNFeWy3dKZXWc=fNOa2UIOMhNDcO3nFEFBdqQSdrQ-KaYNF2GaTgfRsgI=
> .
>

___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=BfGnjYejrGjQ93xAzY1pzA9M9wXXY7rNFeWy3dKZXWc=fNOa2UIOMhNDcO3nFEFBdqQSdrQ-KaYNF2GaTgfRsgI=

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

Re: [netmod] yang-next meeting at IETF 104?

[Robert Wilton]

I would also be interested.  During the week would also be best. Friday 
morning could also be a possibility depending on whether there are 
sessions scheduled.


Thanks,
Rob


On 14/01/2019 17:10, Martin Bjorklund wrote:

Hi,

Andy Bierman  wrote:

Hi,

Is there any interest in 1 or more side meetings at the next IETF to
discuss the yang-next issue list, towards the goal of determining the
problem space in scope for YANG 1.2?

I am interested in this.  I prefer a meeting during the week; my plan
is to arrive Sunday afternoon.


/martin


Those of us who would need to make travel plans would appreciate it
if meetings like this were scheduled ASAP instead of ALAP ;-)


Andy

___
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-next meeting at IETF 104?

[Martin Bjorklund]

Hi,

Andy Bierman  wrote:
> Hi,
> 
> Is there any interest in 1 or more side meetings at the next IETF to
> discuss the yang-next issue list, towards the goal of determining the
> problem space in scope for YANG 1.2?

I am interested in this.  I prefer a meeting during the week; my plan
is to arrive Sunday afternoon.


/martin

> Those of us who would need to make travel plans would appreciate it
> if meetings like this were scheduled ASAP instead of ALAP ;-)
> 
> 
> Andy

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

[netmod] yang-next meeting at IETF 104?

[Andy Bierman]

Hi,

Is there any interest in 1 or more side meetings at the next IETF to
discuss the yang-next issue list, towards the goal of determining the
problem space in scope for YANG 1.2?

Those of us who would need to make travel plans would appreciate it
if meetings like this were scheduled ASAP instead of ALAP ;-)


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

Re: [netmod] yang-next

[Juergen Schoenwaelder]

On Thu, May 12, 2016 at 12:18:08PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, May 12, 2016 at 09:28:25AM +, Bogaert, Bart (Nokia - BE) wrote:
> > > Juergen,
> > > 
> > > Thanks for the feedback.
> > > With respect to functions available when using XPATH: XPATH 1.0 refers to 
> > > a
> > > Core Function Library.  All the functions defined in there (Node set
> > > functions, string functions, Boolean and number functions) are available 
> > > in
> > > a YANG XPATH context?
> > 
> > The YANG specification refers to XPath 1.0 and
> > 
> > https://www.w3.org/TR/1999/REC-xpath-19991116/#corelib
> > 
> > (section 4 Core Function Library) says
> > 
> >   This section describes functions that XPath implementations must
> >   always include in the function library that is used to evaluate
> >   expressions.
> > 
> > and hence I think a compliant implementation must support the XPath
> > 1.0 Core Function Library.
> >  
> > > How wide-spread XPATH 2.0 and 3.0 is I also do not have an idea (I'm
> > > currently "playing" with BaseX and there these versions are supported as 
> > > far
> > > as I know) but the fact that there are multiple versions of the standard 
> > > can
> > > cause confusion about what is "in" and what is "not in".
> > 
> > As far as I understand, libxml2 does not support XPath 2.0 (or 3.0)
> > and having a well maintained open source XPath 2.0 implementation in C
> > is likely of some importance.
> > 
> > > So if, for
> > > RFC6020bis, the supported set of functions is:
> > > 1. the Core Function library of XPATH 1.0
> > > 2. the added functions listed in RFC6020bis
> > > We could conclude that the functionality is "confined".  Maybe a statement
> > > about full support of the Core Function Library of XPATH 1.0 in the RFC
> > > could take away that ambiguity?
> > 
> > I agree that it is not explicitely stated that YANG 1.1 requires the
> > support of 1. and 2.
> 
> See section 6.4.1 of 6020bis, where it explicitly says:
> 
>o  The function library is the core function library defined in
>   [XPATH], and the functions defined in Section 10.
>

Yes, I just found it as well. Good.

/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] yang-next

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, May 12, 2016 at 09:28:25AM +, Bogaert, Bart (Nokia - BE) wrote:
> > Juergen,
> > 
> > Thanks for the feedback.
> > With respect to functions available when using XPATH: XPATH 1.0 refers to a
> > Core Function Library.  All the functions defined in there (Node set
> > functions, string functions, Boolean and number functions) are available in
> > a YANG XPATH context?
> 
> The YANG specification refers to XPath 1.0 and
> 
> https://www.w3.org/TR/1999/REC-xpath-19991116/#corelib
> 
> (section 4 Core Function Library) says
> 
>   This section describes functions that XPath implementations must
>   always include in the function library that is used to evaluate
>   expressions.
> 
> and hence I think a compliant implementation must support the XPath
> 1.0 Core Function Library.
>  
> > How wide-spread XPATH 2.0 and 3.0 is I also do not have an idea (I'm
> > currently "playing" with BaseX and there these versions are supported as far
> > as I know) but the fact that there are multiple versions of the standard can
> > cause confusion about what is "in" and what is "not in".
> 
> As far as I understand, libxml2 does not support XPath 2.0 (or 3.0)
> and having a well maintained open source XPath 2.0 implementation in C
> is likely of some importance.
> 
> > So if, for
> > RFC6020bis, the supported set of functions is:
> > 1. the Core Function library of XPATH 1.0
> > 2. the added functions listed in RFC6020bis
> > We could conclude that the functionality is "confined".  Maybe a statement
> > about full support of the Core Function Library of XPATH 1.0 in the RFC
> > could take away that ambiguity?
> 
> I agree that it is not explicitely stated that YANG 1.1 requires the
> support of 1. and 2.

See section 6.4.1 of 6020bis, where it explicitly says:

   o  The function library is the core function library defined in
  [XPATH], and the functions defined in Section 10.


/martin


> (see above) but if you follow the references to
> XPath 1.0, I think it is implicitely clear.
> 
> /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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-next

[Jernej Tuljak]

Bogaert, Bart (Nokia - BE) je 12.5.2016 ob 11:28 napisal:

Juergen,

Thanks for the feedback.
With respect to functions available when using XPATH: XPATH 1.0 refers to a
Core Function Library.  All the functions defined in there (Node set
functions, string functions, Boolean and number functions) are available in
a YANG XPATH context?


Yes. All functions defined in XPATH spec [1] are available. Usage of 
some of them is discouraged, however. See Section 5.6.2 of usage 
guidelines document [2].


[1] - https://www.w3.org/TR/1999/REC-xpath-19991116/#corelib
[2] - 
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-06#section-5.6.2


Jernej



How wide-spread XPATH 2.0 and 3.0 is I also do not have an idea (I'm
currently "playing" with BaseX and there these versions are supported as far
as I know) but the fact that there are multiple versions of the standard can
cause confusion about what is "in" and what is "not in".  So if, for
RFC6020bis, the supported set of functions is:
1. the Core Function library of XPATH 1.0
2. the added functions listed in RFC6020bis
We could conclude that the functionality is "confined".  Maybe a statement
about full support of the Core Function Library of XPATH 1.0 in the RFC
could take away that ambiguity?

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.

-Original Message-
From: EXT Juergen Schoenwaelder
[mailto:j.schoenwael...@jacobs-university.de]
Sent: 12 May 2016 10:57
To: Bogaert, Bart (Nokia - BE)
Cc: netmod@ietf.org
Subject: Re: [netmod] yang-next

On Thu, May 12, 2016 at 08:33:36AM +, Bogaert, Bart (Nokia - BE) wrote:

Hi,

Not sure whether this has been requested before but has it ever been

considered to support higher versions of XPATH in YANG?  As far as I
remember only XPATH 1.0 is supported in YANG although the RFC mentions
adopting of XPATH 2.0 with respect to handling of unprefixed names.
RFC6020bis lists a set of functions that have been added and that are
available in an XPATH context.  XPATH itself at this moment is at version
3.1.  Some questions:

- are there any plans to follow the XPATH evolution in YANG?

So far, XPATH 2.0 has been considered too complex to require and there were
concerns of how widespread support there is for XPATH 2.0 (and
3.0 was never mentioned I think).


- to me at least it is not specifically clear what is and what is not

supported w.r.t. XPATH in YANG.  Is there no clarification required in this
context?

Can you further detail what you find missing or unclear in
draft-ietf-netmod-rfc6020bis-12.txt regarding xpath? Simply search for
xpath, there is quite some text in various places.


Certain checks can't be expressed using an XPATH and require XQUERY (e.g.

when one need to follow a linked list in case of a lookup of a specific
node).  Are there any plans to include support for XQUERY in YANG?

So far not.

Note that the goal so far has been to be somewhat conservative, that is, to
add features based on a good understanding which real-world problems are
being solved and ideally based on implementation and even better early
deployment experience. (A new feature that has been implemented and
successfully used as proprietary extensions is likely more important to
consider than something that exists as an idea on paper only).

/js



___
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-next

[Bogaert, Bart (Nokia - BE)]

Juergen,

Thanks for the feedback.
With respect to functions available when using XPATH: XPATH 1.0 refers to a
Core Function Library.  All the functions defined in there (Node set
functions, string functions, Boolean and number functions) are available in
a YANG XPATH context?

How wide-spread XPATH 2.0 and 3.0 is I also do not have an idea (I'm
currently "playing" with BaseX and there these versions are supported as far
as I know) but the fact that there are multiple versions of the standard can
cause confusion about what is "in" and what is "not in".  So if, for
RFC6020bis, the supported set of functions is:
1. the Core Function library of XPATH 1.0
2. the added functions listed in RFC6020bis
We could conclude that the functionality is "confined".  Maybe a statement
about full support of the Core Function Library of XPATH 1.0 in the RFC
could take away that ambiguity?

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.
>> 


-Original Message-
From: EXT Juergen Schoenwaelder
[mailto:j.schoenwael...@jacobs-university.de] 
Sent: 12 May 2016 10:57
To: Bogaert, Bart (Nokia - BE)
Cc: netmod@ietf.org
Subject: Re: [netmod] yang-next

On Thu, May 12, 2016 at 08:33:36AM +, Bogaert, Bart (Nokia - BE) wrote:
> Hi,
> 
> Not sure whether this has been requested before but has it ever been
considered to support higher versions of XPATH in YANG?  As far as I
remember only XPATH 1.0 is supported in YANG although the RFC mentions
adopting of XPATH 2.0 with respect to handling of unprefixed names.
RFC6020bis lists a set of functions that have been added and that are
available in an XPATH context.  XPATH itself at this moment is at version
3.1.  Some questions:
> - are there any plans to follow the XPATH evolution in YANG?

So far, XPATH 2.0 has been considered too complex to require and there were
concerns of how widespread support there is for XPATH 2.0 (and
3.0 was never mentioned I think).

> - to me at least it is not specifically clear what is and what is not
supported w.r.t. XPATH in YANG.  Is there no clarification required in this
context?

Can you further detail what you find missing or unclear in
draft-ietf-netmod-rfc6020bis-12.txt regarding xpath? Simply search for
xpath, there is quite some text in various places.

> Certain checks can't be expressed using an XPATH and require XQUERY (e.g.
when one need to follow a linked list in case of a lookup of a specific
node).  Are there any plans to include support for XQUERY in YANG?

So far not.

Note that the goal so far has been to be somewhat conservative, that is, to
add features based on a good understanding which real-world problems are
being solved and ideally based on implementation and even better early
deployment experience. (A new feature that has been implemented and
successfully used as proprietary extensions is likely more important to
consider than something that exists as an idea on paper only).

/js

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-next

[Juergen Schoenwaelder]

On Thu, May 12, 2016 at 08:33:36AM +, Bogaert, Bart (Nokia - BE) wrote:
> Hi,
> 
> Not sure whether this has been requested before but has it ever been 
> considered to support higher versions of XPATH in YANG?  As far as I remember 
> only XPATH 1.0 is supported in YANG although the RFC mentions adopting of 
> XPATH 2.0 with respect to handling of unprefixed names.  RFC6020bis lists a 
> set of functions that have been added and that are available in an XPATH 
> context.  XPATH itself at this moment is at version 3.1.  Some questions:
> - are there any plans to follow the XPATH evolution in YANG?

So far, XPATH 2.0 has been considered too complex to require and there
were concerns of how widespread support there is for XPATH 2.0 (and
3.0 was never mentioned I think).

> - to me at least it is not specifically clear what is and what is not 
> supported w.r.t. XPATH in YANG.  Is there no clarification required in this 
> context?

Can you further detail what you find missing or unclear in
draft-ietf-netmod-rfc6020bis-12.txt regarding xpath? Simply search for
xpath, there is quite some text in various places.

> Certain checks can't be expressed using an XPATH and require XQUERY (e.g. 
> when one need to follow a linked list in case of a lookup of a specific 
> node).  Are there any plans to include support for XQUERY in YANG?

So far not.

Note that the goal so far has been to be somewhat conservative, that
is, to add features based on a good understanding which real-world
problems are being solved and ideally based on implementation and even
better early deployment experience. (A new feature that has been
implemented and successfully used as proprietary extensions is likely
more important to consider than something that exists as an idea on
paper only).

/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] yang-next

[Bogaert, Bart (Nokia - BE)]

Hi,

Not sure whether this has been requested before but has it ever been considered 
to support higher versions of XPATH in YANG?  As far as I remember only XPATH 
1.0 is supported in YANG although the RFC mentions adopting of XPATH 2.0 with 
respect to handling of unprefixed names.  RFC6020bis lists a set of functions 
that have been added and that are available in an XPATH context.  XPATH itself 
at this moment is at version 3.1.  Some questions:
- are there any plans to follow the XPATH evolution in YANG?
- to me at least it is not specifically clear what is and what is not supported 
w.r.t. XPATH in YANG.  Is there no clarification required in this context?

Certain checks can't be expressed using an XPATH and require XQUERY (e.g. when 
one need to follow a linked list in case of a lookup of a specific node).  Are 
there any plans to include support for XQUERY in YANG?

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law. If you 
are not the intended recipient, you should delete this message. Any disclosure, 
copying, or distribution of this message, or the taking of any action based on 
it, is strictly prohibited without the prior consent of its author.
>> 

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of EXT Martin Bjorklund
Sent: 11 March 2016 11:18
To: kwat...@juniper.net
Cc: netmod@ietf.org
Subject: Re: [netmod] yang-next

Hi,

Kent Watsen <kwat...@juniper.net> wrote:
> 
> All,
> 
> I see too many emails go by where someone has an idea that they’d like 
> to get into a future version of YANG, and keep wishing that there were 
> an easy way to capture these feature requests.  With that in mind I 
> created a new Github repository called "yang-next”.  This repository 
> is not for a draft, yet, its current existence is solely to have a 
> publicly editable issue tracker.  Please feel free to add all your 
> good ideas (just one idea per issue please) here:
> https://github.com/netmod-wg/yang-next/issues.

I think it is a good idea to capture ideas like this, but I also think that 
such ideas should be discussed on the ML.  But maybe that's what you meant.


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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-next

[Lou Berger]

I tried and failed to  the repo to email events to the list.

If anyone knows how to do this, please send mail to netmod-cha...@ietf.org.

Thanks,
Lou


On 3/11/2016 5:17 AM, Martin Bjorklund wrote:
> I think it is a good idea to capture ideas like this, but I also think
> that such ideas should be discussed on the ML.


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

Re: [netmod] yang-next

[Kent Watsen]

>I think it is a good idea to capture ideas like this, but I also think
>that such ideas should be discussed on the ML.  But maybe that's what
>you meant.


My thought is to defer any discussion on the ML until we actually want to start 
working on yang-next.  That said, it would be good to ensure that any issues 
posted in the interim are suitably captured; that what’s being asked for is 
clearly understood.   Of course, we could at a later point in time reach out to 
the github userid to ask for a clarification and, in the case of no response, 
either do our best or drop it.  To me, it is sufficient to just capture the 
ideas, with no discussion happening until later and then, of course, they would 
be on the ML.

Thanks,
Kent

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

Re: [netmod] yang-next

[Kent Watsen]

I was just thinking about how we always talk about yang-1.1, yang-1.2, 
yang-2.0, so I figured yang-next  ;)


From: "Alexander Clemm (alex)" <a...@cisco.com<mailto:a...@cisco.com>>
Date: Thursday, March 10, 2016 at 9:29 PM
To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: RE: yang-next

How about calling it YANGNG?
Cheers
--- Alex

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Thursday, March 10, 2016 6:13 PM
To: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: [netmod] yang-next


All,

I see too many emails go by where someone has an idea that they’d like to get 
into a future version of YANG, and keep wishing that there were an easy way to 
capture these feature requests.  With that in mind I created a new Github 
repository called "yang-next”.This repository is not for a draft, yet, its 
current existence is solely to have a publicly editable issue tracker.   Please 
feel free to add all your good ideas (just one idea per issue please) here: 
https://github.com/netmod-wg/yang-next/issues.

Cheers,
Kent




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

Re: [netmod] yang-next

[Alexander Clemm (alex)]

How about calling it YANGNG?
Cheers
--- Alex

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Thursday, March 10, 2016 6:13 PM
To: netmod@ietf.org
Subject: [netmod] yang-next


All,

I see too many emails go by where someone has an idea that they’d like to get 
into a future version of YANG, and keep wishing that there were an easy way to 
capture these feature requests.  With that in mind I created a new Github 
repository called "yang-next”.This repository is not for a draft, yet, its 
current existence is solely to have a publicly editable issue tracker.   Please 
feel free to add all your good ideas (just one idea per issue please) here: 
https://github.com/netmod-wg/yang-next/issues.

Cheers,
Kent




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