Re: [netmod]  CoRE Working Group Adoption call for draft-veillette-core-yang-library-05.txt

[Carsten Bormann]

So this was a very thin response on a WG adoption call on the mailing list, but 
given the sense of the room on Tuesday, I think we can accept this as a WG 
draft.
We do have the WG last call as another formal opportunity to stop this if it 
turns out this can be done in a way that preserves full compatibility with RFC 
8525.

We are now waiting for a final WGLC-ready I-D version of yang-cbor (one 
internal author review is outstanding), and then will WGLC the whole cluster 
(yang-cbor, sid, comi, core-yang-library) in the CoRE WG with a CC to the CCs 
of this mail.
This WGLC will not go through without a number of high-quality reviews.

Grüße, Carsten


> On Jul 11, 2019, at 09:44, Carsten Bormann  wrote:
> 
> RFC 8525 defines a YANG data model for information about the YANG modules, 
> datastores, and datastore schemas used by a network management server.   This 
> data model is based on string representations of YANG identifiers.
> 
> To be more useful in a constrained environment (CoRECONF/COMI), it is useful 
> to have a YANG data model that can employ the efficiency of SIDs 
> (draft-ietf-core-sid).  draft-veillette-core-yang-library-05.txt provides a 
> straightforward translation of RFC 8525 to SID-based identification, with 
> some legacy support removed and some other efficiencies added.  This 
> specification complements the three other CoRECONF specifications 
> draft-ietf-core-yang-cbor, draft-ietf-core-sid, and draft-ietf-core-comi, 
> which we hope to ship soon.
> 
> This starts a one-week working group adoption call.
> This is a formal call for adoption of this draft as a WG document of the CoRE 
> WG.
> If you have read the draft and support adopting it, please say so.
> If you see a problem with adopting it as a WG document, please tell us.
> For both, remember that WG adoption does not mean that we already have 
> consensus on all the details(*), just that this is the right working document 
> to address the issue (and that we should address the issue in the first 
> place); you are encouraged to mention any issues that you already know.
> 
> This WGA call is CCed to the netconf and netmod working groups, as the 
> expertise about YANG modules is focused there, as well as the yang-of-things 
> non-WG mailing list.  Please respond to c...@ietf.org, or exceptionally to 
> core-cha...@ietf.org (for off-list comments).
> 
> This formal WG adoption call runs until the end of July 18th.
> 
> Grüße, Carsten
> 
> (*) say, is the module-set index really limited to an 8-bit number?
> 
> 
> 

___
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 
 

 

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

[netmod] Publication has been requested for draft-ietf-netmod-artwork-folding-07

[Lou Berger via Datatracker]

Lou Berger has requested publication of draft-ietf-netmod-artwork-folding-07 as 
Best Current Practice on behalf of the NETMOD working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/

___
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

[netmod] I-D Action: draft-ietf-netmod-artwork-folding-07.txt

[internet-drafts]

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

Title   : Handling Long Lines in Inclusions in Internet-Drafts 
and RFCs
Authors : Kent Watsen
  Adrian Farrel
  Qin Wu
Filename: draft-ietf-netmod-artwork-folding-07.txt
Pages   : 27
Date: 2019-07-24

Abstract:
   This document defines two strategies for handling long lines in
   width-bounded text content.  One strategy is based on the historic
   use of a single backslash ('\') character to indicate where line-
   folding has occurred, with the continuation occurring with the first
   non-space (' ') character on the next line.  The second strategy
   extends the first strategy by adding a second backslash character to
   identify where the continuation begins and thereby able to handle
   cases not supported by the first strategy.  Both strategies use a
   self-describing header enabling automated reconstitution of the
   original content.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-07
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-artwork-folding-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-07


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

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

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

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 

-- 
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] 6991bis: domain-name

[Ladislav Lhotka]

On Wed, 2019-07-24 at 10:18 +0100, William Lupton wrote:
> I think that "or" is slightly better here:
> 
> "...does not support wildcards (see RFC 4592) or classless in-addr.arpa
> delegations (see RFC 2317)"

I agree, thanks.

Lada

> 
> On Wed, 24 Jul 2019 at 08:01, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > On Mon, Jul 22, 2019 at 06:41:42PM -0400, Ladislav Lhotka wrote:
> > > 
> > > But these two unsupported cases only make sense in the context of DNS zone
> > data.
> > > I would suggest instead
> > > 
> > > NEW:
> > > 
> > > "The domain-name type represents a DNS domain name.  The
> > >  name SHOULD be fully qualified whenever possible.
> > >  This type is not intended for modeling DNS zone data, as
> > >  it does not support wildcards [RFC 4592] and classless
> > >  in-addr.arpa delegations [RFC 2317]." 
> > >
> > 
> > Yes, this is better. I will put the following in the next revision:
> > 
> >  "The domain-name type represents a DNS domain name.  The
> >   name SHOULD be fully qualified whenever possible. This
> >   type does not support wildcards (see RFC 4592) and
> >   classless in-addr.arpa delegations (see RFC 2317).
> > 
> > And I will remove the sentence you wanted to remove since the above
> > more clearly explains when to use / not to use this type.
> > 
> > /js
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] 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



发件人： 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] 6991bis: domain-name

[Juergen Schoenwaelder]

Yes, changed in my sources.

/js

On Wed, Jul 24, 2019 at 10:18:32AM +0100, William Lupton wrote:
> I think that "or" is slightly better here:
> 
> "...does not support wildcards (see RFC 4592) *or* classless in-addr.arpa
> delegations (see RFC 2317)"
> 
> On Wed, 24 Jul 2019 at 08:01, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Mon, Jul 22, 2019 at 06:41:42PM -0400, Ladislav Lhotka wrote:
> > >
> > > But these two unsupported cases only make sense in the context of DNS
> > zone data.
> > > I would suggest instead
> > >
> > > NEW:
> > >
> > > "The domain-name type represents a DNS domain name.  The
> > >  name SHOULD be fully qualified whenever possible.
> > >  This type is not intended for modeling DNS zone data, as
> > >  it does not support wildcards [RFC 4592] and classless
> > >  in-addr.arpa delegations [RFC 2317]."
> > >
> >
> > Yes, this is better. I will put the following in the next revision:
> >
> >  "The domain-name type represents a DNS domain name.  The
> >   name SHOULD be fully qualified whenever possible. This
> >   type does not support wildcards (see RFC 4592) and
> >   classless in-addr.arpa delegations (see RFC 2317).
> >
> > And I will remove the sentence you wanted to remove since the above
> > more clearly explains when to use / not to use this type.
> >
> > /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
> >

-- 
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] 6991bis: domain-name

[William Lupton]

I think that "or" is slightly better here:

"...does not support wildcards (see RFC 4592) *or* classless in-addr.arpa
delegations (see RFC 2317)"

On Wed, 24 Jul 2019 at 08:01, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Mon, Jul 22, 2019 at 06:41:42PM -0400, Ladislav Lhotka wrote:
> >
> > But these two unsupported cases only make sense in the context of DNS
> zone data.
> > I would suggest instead
> >
> > NEW:
> >
> > "The domain-name type represents a DNS domain name.  The
> >  name SHOULD be fully qualified whenever possible.
> >  This type is not intended for modeling DNS zone data, as
> >  it does not support wildcards [RFC 4592] and classless
> >  in-addr.arpa delegations [RFC 2317]."
> >
>
> Yes, this is better. I will put the following in the next revision:
>
>  "The domain-name type represents a DNS domain name.  The
>   name SHOULD be fully qualified whenever possible. This
>   type does not support wildcards (see RFC 4592) and
>   classless in-addr.arpa delegations (see RFC 2317).
>
> And I will remove the sentence you wanted to remove since the above
> more clearly explains when to use / not to use this type.
>
> /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] 6991bis: domain-name

[Juergen Schoenwaelder]

On Mon, Jul 22, 2019 at 06:41:42PM -0400, Ladislav Lhotka wrote:
> 
> But these two unsupported cases only make sense in the context of DNS zone 
> data.
> I would suggest instead
> 
> NEW:
> 
> "The domain-name type represents a DNS domain name.  The
>  name SHOULD be fully qualified whenever possible.
>  This type is not intended for modeling DNS zone data, as
>  it does not support wildcards [RFC 4592] and classless
>  in-addr.arpa delegations [RFC 2317]." 
>

Yes, this is better. I will put the following in the next revision:

 "The domain-name type represents a DNS domain name.  The
  name SHOULD be fully qualified whenever possible. This
  type does not support wildcards (see RFC 4592) and
  classless in-addr.arpa delegations (see RFC 2317).

And I will remove the sentence you wanted to remove since the above
more clearly explains when to use / not to use this type.

/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