Re: [netmod] Poll on YANG Versioning NBC Approach

[Kent Watsen]

[All, don’t forget to vote, discussion here doesn’t count!  
https://notes.ietf.org/netmod-2023-sept-poll]


> On Sep 12, 2023, at 12:06 PM, Andy Bierman  wrote:
> 
> So there is choice between:
> 
>   (A) YANG 1.1 and SHOULD NOT
>   (B) YANG 1.2 and SHOULD NOT

Thanks Andy, this is a succinct way to frame it.

  
> (A) is acceptable.
> YANG 1.2 would create a false expectation in the user community that the IETF
> had improved the YANG language somehow.

Agreed.


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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Tue, Sep 12, 2023 at 8:54 AM Reshad Rahman  wrote:

>
>
> On Tuesday, September 12, 2023, 11:23:55 AM EDT, Andy Bierman <
> a...@yumaworks.com> wrote:
>
>
>
>
> On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen  wrote:
>
> WG,
>
> Please help the YANG-versioning effort move forward by participating in
> the following poll:
>
>   - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login
> required)
>
>
>
> The draft proposed to change many specific MUST and MUST NOT requirements
> to MAY ignore.
> It has been pointed out that the correct change would be SHOULD NOT and
> the use of MAY is inappropriate
> according to the definitions in RFC 2119.
>  I thought the authors had agreed on SHOULD NOT (instead of MAY), but
> I don't recall if this was just in the weekly calls or actually
> communicated to the wg alias.
>
>
So there is choice between:

  (A) YANG 1.1 and SHOULD NOT
  (B) YANG 1.2 and SHOULD NOT

(A) is acceptable.
YANG 1.2 would create a false expectation in the user community that the
IETF
had improved the YANG language somehow.


> Regards,
> Reshad.
>

Andy


>
> Yet the WG continues to propose that these rules in RFC 7950 are purely
> optional and can be ignored by
> any implementation that chooses to do so.
>
> Of course rules that affect backward compatibility and stability do not
> affect the code that compiles a module.
> They only affect the client code that attempts to use the unstable server
> code.
>
>
>
> Kent and Lou
>
>
> 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Poll on YANG Versioning NBC Approach

[Reshad Rahman]

 

On Tuesday, September 12, 2023, 11:23:55 AM EDT, Andy Bierman 
 wrote:  
 
 

On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen  wrote:

WG,
Please help the YANG-versioning effort move forward by participating in the 
following poll:
  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)



The draft proposed to change many specific MUST and MUST NOT requirements to 
MAY ignore.It has been pointed out that the correct change would be SHOULD NOT 
and the use of MAY is inappropriateaccording to the definitions in RFC 
2119. I thought the authors had agreed on SHOULD NOT (instead of MAY), but 
I don't recall if this was just in the weekly calls or actually communicated to 
the wg alias.
Regards,Reshad.
Yet the WG continues to propose that these rules in RFC 7950 are purely 
optional and can be ignored byany implementation that chooses to do so.
Of course rules that affect backward compatibility and stability do not affect 
the code that compiles a module.They only affect the client code that attempts 
to use the unstable server code.



Kent and Lou

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
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen  wrote:

> WG,
>
> Please help the YANG-versioning effort move forward by participating in
> the following poll:
>
>   - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login
> required)
>
>

The draft proposed to change many specific MUST and MUST NOT requirements
to MAY ignore.
It has been pointed out that the correct change would be SHOULD NOT and the
use of MAY is inappropriate
according to the definitions in RFC 2119.

Yet the WG continues to propose that these rules in RFC 7950 are purely
optional and can be ignored by
any implementation that chooses to do so.

Of course rules that affect backward compatibility and stability do not
affect the code that compiles a module.
They only affect the client code that attempts to use the unstable server
code.



Kent and Lou
>

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] Poll on YANG Versioning NBC Approach

[Ladislav Lhotka]

Dne 12. 09. 23 v 14:43 Jan Lindblad (jlindbla) napsal(a):

Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the YANG language 
version number, but digging a bit deeper, I think the question is not as 
clear-cut as it might seem at first.

Altering the contents of the backwards-compatibility section of RFC 6020 (sec 
10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' 
behavior.

Speaking as a YANG compiler implementor, however, I don't see any changes that 
have to made to the compiler because of this RFC change. There are no new 
keywords, none are removed. There is no change in the meaning of existing 
keywords. There is no difference in the output the compiler needs to generate.

So while there are changes to the YANG *standard* (meaning RFCs) there is no actual 
change to the YANG *language*. If we require user's to mark their modules with version 
1.2 (or 2.0), from the compiler's pov, that would just be an alias for YANG 1.1. It means 
a fair amount of trouble to update all the tools out there to accept "yang-version 
1.2" but do nothing new. It also adds a burden to YANG module implementors, since 
they would have to go through all YANG 1.1 modules and mark them 1.2, for no change in 
meaning. For organizations with some modules still on YANG 1.0, the bar is even higher.

I think the most pragmatic approach in this case would be to change the RFC 
text in the backwards-compatibility sections and not update the yang-version 
number as long as no change is required in the compilers. If anyone can point 
to actual things the compiler needs to do differently, I'd be interested to 
hear.


I agree with this. I have actually always thought that the section 
"Updating a Module" should never have become part of the YANG language 
definition. A sensible approach could IMO be to move this section to 
8407bis, and relax the requirements to SHOULD there.


Lada



Best Regards,
/jan




On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
 wrote:

I disagree with the poll. There are important teachnigal differences
behind the two options that this polls tries to hide.

Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
1.1'. There is no way that a new versioning approach will be
understood by existing YANG tooling. That's an illusion.

/js

On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:

WG,

Please help the YANG-versioning effort move forward by participating in the 
following poll:

  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)

Kent and Lou




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



--
Jürgen Schönwälder  Constructor 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


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

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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Rob Wilton (rwilton)]

Hi Jürgen,

Please see inline ...

> -Original Message-
> From: netmod  On Behalf Of Jürgen
> Schönwälder
> Sent: 12 September 2023 14:11
> To: Jan Lindblad (jlindbla) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> 
> The two options mix things together. Option 1 says updating YANG 1 and
> YANG 1.1 to allow YANG modules to be modified _based on
> draft-ietf-netmod-yang-module-versioning_ but this document has much
> more in it than just changing a MUST to SHOULD.
[Rob Wilton (rwilton)] 

I think that for this first poll this is the question that we should initially 
focus on.  I.e., at a starting point, do you agree to updating RFC 6020, RFC 
7950, to allow changing the MUST to a SHOULD without a new YANG 1.2?

If we can get consensus on this part, then I think that we can try and tackle 
getting consensus on the other updates in 
draft-ietf-netmod-yang-module-versioning to decide whether to include those in 
a document that updates existing versions of YANG without a change in the YANG 
versioning number, or whether those changes should be deferred to a new version 
of YANG (which I hope that the WG starts after this versioning work completes - 
but I'll no longer be an AD at that stage).


> 
> There are features in draft-ietf-netmod-yang-module-versioning that
> you can use only with new tools that implement the features. I am not
> sure why tools that support different variants of YANG 1 and YANG 1.1
> are any easier in practice than a tool that says clearly what it
> implements.
[Rob Wilton (rwilton)] 

I hear two concerns:
(1) Existing tooling handling YANG 1 and YANG 1.1 modules must handle NBC 
changes anyway because they see them in the wild and that won't change.  E.g., 
it is 99% likely that OpenConfig will still continue to use Yang 1 modules.
(2) All existing tooling won't be able to handle YANG 1.2 without tooling 
changes. 

> 
> I continue to believe the questions are badly phrased. Instead of
> discussing properties and trade-offs of solutions, we discuss the
> version number. And we accept that bumping the version number is
> considered too costly but at the same time the entire work is about
> introducing version numbers to data models (where the same logic will
> sooner of later apply). Yes, for me, this is real-world irony.
[Rob Wilton (rwilton)] 

I see this as: What are we able to do now without changing the YANG versioning 
number, and without breaking existing tools, to help solve real world issues 
today?  I.e., the aim is to bound our solution by what we are pragmatically 
able to support in YANG 1/YANG 1.1 without breaking existing tooling (which 
should already ignore existing statements that they don't understand).

Yang 1.2/2 should be worked on, but that will probably include other changes as 
well and involve some level of effort from tool vendors to support.  It will 
also probably also take many years.

Regards,
Rob


> 
> /js
> 
> PS: There is no need to update YANG 1.1 modules to YANG 1.2 as long
> as you do not use YANG 1.2 rules and mechanism.
> 
> On Tue, Sep 12, 2023 at 12:43:56PM +, Jan Lindblad (jlindbla) wrote:
> > Jürgen, all,
> >
> > I see the irony in changing the YANG RFC(s) without updating the YANG
> language version number, but digging a bit deeper, I think the question is not
> as clear-cut as it might seem at first.
> >
> > Altering the contents of the backwards-compatibility section of RFC 6020
> (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG module
> authors' behavior.
> >
> > Speaking as a YANG compiler implementor, however, I don't see any
> changes that have to made to the compiler because of this RFC change. There
> are no new keywords, none are removed. There is no change in the meaning
> of existing keywords. There is no difference in the output the compiler needs
> to generate.
> >
> > So while there are changes to the YANG *standard* (meaning RFCs) there is
> no actual change to the YANG *language*. If we require user's to mark their
> modules with version 1.2 (or 2.0), from the compiler's pov, that would just
> be an alias for YANG 1.1. It means a fair amount of trouble to update all the
> tools out there to accept "yang-version 1.2" but do nothing new. It also adds
> a burden to YANG module implementors, since they would have to go
> through all YANG 1.1 modules and mark them 1.2, for no change in meaning.
> For organizations with some modules still on YANG 1.0, the bar is even
> higher.
> >
> > I think the most pragmatic approach in this case would be to change the
> RFC text in the backwards-compatibility sections and not update the yang-
> version number as long as no change is required in the compilers. If anyone
> can point to actual things the compiler needs to do differently, I'd be
> interested to hear.
> >
> > Best Regards,
> > /jan
> >
> >
> >
> > > On 12 Sep 2023, at 07:55, Jürgen Schönwälder
>  wrote:
> > >
> > > I disagree with the poll. There are important 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jürgen Schönwälder]

The two options mix things together. Option 1 says updating YANG 1 and
YANG 1.1 to allow YANG modules to be modified _based on
draft-ietf-netmod-yang-module-versioning_ but this document has much
more in it than just changing a MUST to SHOULD.

There are features in draft-ietf-netmod-yang-module-versioning that
you can use only with new tools that implement the features. I am not
sure why tools that support different variants of YANG 1 and YANG 1.1
are any easier in practice than a tool that says clearly what it
implements.

I continue to believe the questions are badly phrased. Instead of
discussing properties and trade-offs of solutions, we discuss the
version number. And we accept that bumping the version number is
considered too costly but at the same time the entire work is about
introducing version numbers to data models (where the same logic will
sooner of later apply). Yes, for me, this is real-world irony.

/js

PS: There is no need to update YANG 1.1 modules to YANG 1.2 as long
as you do not use YANG 1.2 rules and mechanism.

On Tue, Sep 12, 2023 at 12:43:56PM +, Jan Lindblad (jlindbla) wrote:
> Jürgen, all,
> 
> I see the irony in changing the YANG RFC(s) without updating the YANG 
> language version number, but digging a bit deeper, I think the question is 
> not as clear-cut as it might seem at first.
> 
> Altering the contents of the backwards-compatibility section of RFC 6020 (sec 
> 10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' 
> behavior.
> 
> Speaking as a YANG compiler implementor, however, I don't see any changes 
> that have to made to the compiler because of this RFC change. There are no 
> new keywords, none are removed. There is no change in the meaning of existing 
> keywords. There is no difference in the output the compiler needs to generate.
> 
> So while there are changes to the YANG *standard* (meaning RFCs) there is no 
> actual change to the YANG *language*. If we require user's to mark their 
> modules with version 1.2 (or 2.0), from the compiler's pov, that would just 
> be an alias for YANG 1.1. It means a fair amount of trouble to update all the 
> tools out there to accept "yang-version 1.2" but do nothing new. It also adds 
> a burden to YANG module implementors, since they would have to go through all 
> YANG 1.1 modules and mark them 1.2, for no change in meaning. For 
> organizations with some modules still on YANG 1.0, the bar is even higher.
> 
> I think the most pragmatic approach in this case would be to change the RFC 
> text in the backwards-compatibility sections and not update the yang-version 
> number as long as no change is required in the compilers. If anyone can point 
> to actual things the compiler needs to do differently, I'd be interested to 
> hear.
> 
> Best Regards,
> /jan
> 
> 
> 
> > On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
> >  wrote:
> > 
> > I disagree with the poll. There are important teachnigal differences
> > behind the two options that this polls tries to hide.
> > 
> > Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> > 1.1'. There is no way that a new versioning approach will be
> > understood by existing YANG tooling. That's an illusion.
> > 
> > /js
> > 
> > On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
> >> WG,
> >> 
> >> Please help the YANG-versioning effort move forward by participating in 
> >> the following poll:
> >> 
> >>  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login 
> >> required)
> >> 
> >> Kent and Lou
> >> 
> > 
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> > 
> > 
> > -- 
> > Jürgen Schönwälder  Constructor 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
> 

-- 
Jürgen Schönwälder  Constructor 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] Poll on YANG Versioning NBC Approach

[Rob Wilton (rwilton)]

Further to Jan's comments, given that all organizations (vendors, SDOs, and 
industry consortia) producing YANG modules all occasionally update then in NBC 
ways to fix bugs and issues, then I presume that all pragmatic YANG tooling is 
obliged to handle cases where modules change in NBC ways.

Hence, I see changing the following paragraph in RFC 7950 section 11 from

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.

to

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this SHOULD be achieved by a
   new definition with a new identifier.

really as bugfix to RFC 7950 (given that it how everyone is interpreting it) 
rather than a new version of YANG.

If, the landscape was different and everyone defining YANG 1 and YANG 1.1 
modules was only making BC changes, then I would advocate for a new version of 
YANG, but that is not where we are, as has Jan as explained below, I think that 
defining a new version of YANG for this will just cause pain/confusion rather 
than any wider benefit to the industry.

Regards,
Rob

// As a contributor



> -Original Message-
> From: netmod  On Behalf Of Jan Lindblad
> (jlindbla)
> Sent: 12 September 2023 13:44
> To: Jürgen Schönwälder 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> 
> Jürgen, all,
> 
> I see the irony in changing the YANG RFC(s) without updating the YANG
> language version number, but digging a bit deeper, I think the question is not
> as clear-cut as it might seem at first.
> 
> Altering the contents of the backwards-compatibility section of RFC 6020 (sec
> 10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors'
> behavior.
> 
> Speaking as a YANG compiler implementor, however, I don't see any changes
> that have to made to the compiler because of this RFC change. There are no
> new keywords, none are removed. There is no change in the meaning of
> existing keywords. There is no difference in the output the compiler needs to
> generate.
> 
> So while there are changes to the YANG *standard* (meaning RFCs) there is
> no actual change to the YANG *language*. If we require user's to mark their
> modules with version 1.2 (or 2.0), from the compiler's pov, that would just
> be an alias for YANG 1.1. It means a fair amount of trouble to update all the
> tools out there to accept "yang-version 1.2" but do nothing new. It also adds
> a burden to YANG module implementors, since they would have to go
> through all YANG 1.1 modules and mark them 1.2, for no change in meaning.
> For organizations with some modules still on YANG 1.0, the bar is even
> higher.
> 
> I think the most pragmatic approach in this case would be to change the RFC
> text in the backwards-compatibility sections and not update the yang-version
> number as long as no change is required in the compilers. If anyone can
> point to actual things the compiler needs to do differently, I'd be interested
> to hear.
> 
> Best Regards,
> /jan
> 
> 
> 
> > On 12 Sep 2023, at 07:55, Jürgen Schönwälder
>  wrote:
> >
> > I disagree with the poll. There are important teachnigal differences
> > behind the two options that this polls tries to hide.
> >
> > Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> > 1.1'. There is no way that a new versioning approach will be
> > understood by existing YANG tooling. That's an illusion.
> >
> > /js
> >
> > On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
> >> WG,
> >>
> >> Please help the YANG-versioning effort move forward by participating in
> the following poll:
> >>
> >>  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login
> required)
> >>
> >> Kent and Lou
> >>
> >
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > --
> > Jürgen Schönwälder  Constructor 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jan Lindblad (jlindbla)]

Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the YANG language 
version number, but digging a bit deeper, I think the question is not as 
clear-cut as it might seem at first.

Altering the contents of the backwards-compatibility section of RFC 6020 (sec 
10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' 
behavior.

Speaking as a YANG compiler implementor, however, I don't see any changes that 
have to made to the compiler because of this RFC change. There are no new 
keywords, none are removed. There is no change in the meaning of existing 
keywords. There is no difference in the output the compiler needs to generate.

So while there are changes to the YANG *standard* (meaning RFCs) there is no 
actual change to the YANG *language*. If we require user's to mark their 
modules with version 1.2 (or 2.0), from the compiler's pov, that would just be 
an alias for YANG 1.1. It means a fair amount of trouble to update all the 
tools out there to accept "yang-version 1.2" but do nothing new. It also adds a 
burden to YANG module implementors, since they would have to go through all 
YANG 1.1 modules and mark them 1.2, for no change in meaning. For organizations 
with some modules still on YANG 1.0, the bar is even higher.

I think the most pragmatic approach in this case would be to change the RFC 
text in the backwards-compatibility sections and not update the yang-version 
number as long as no change is required in the compilers. If anyone can point 
to actual things the compiler needs to do differently, I'd be interested to 
hear.

Best Regards,
/jan



> On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
>  wrote:
> 
> I disagree with the poll. There are important teachnigal differences
> behind the two options that this polls tries to hide.
> 
> Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> 1.1'. There is no way that a new versioning approach will be
> understood by existing YANG tooling. That's an illusion.
> 
> /js
> 
> On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
>> WG,
>> 
>> Please help the YANG-versioning effort move forward by participating in the 
>> following poll:
>> 
>>  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)
>> 
>> Kent and Lou
>> 
> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> -- 
> Jürgen Schönwälder  Constructor 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] Poll on YANG Versioning NBC Approach

[Jürgen Schönwälder]

Versioning people told me that the version numbers follows from the
kind of changes made. If true, then discussing the version number
first is backwards.

/js

On Tue, Sep 12, 2023 at 11:59:45AM +, Jason Sterne (Nokia) wrote:
> Hi Jurgen,
> 
> We need this poll to set fundamental direction in the WG. Yes, there will 
> still be discussion & debate around *either* option once we select one. But 
> we need to agree on whether we're moving ahead by updating YANG 1.0/YANG 1.1 
> (without requiring any sort of new YANG version number) or if we as a WG are 
> going to insist on only allowing this work to continue and exist in YANG 
> modules marked with a new YANG version 1.2.
> 
> We need to put this part of the decision behind us and move onto the next set 
> of discussions & issues.
> 
> Jason
> 
> > -Original Message-
> > From: netmod  On Behalf Of Jürgen Schönwälder
> > Sent: Tuesday, September 12, 2023 1:55 AM
> > To: Kent Watsen 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> > 
> > 
> > CAUTION: This is an external email. Please be very careful when clicking 
> > links or
> > opening attachments. See the URL nok.it/ext for additional information.
> > 
> > 
> > 
> > I disagree with the poll. There are important teachnigal differences
> > behind the two options that this polls tries to hide.
> > 
> > Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> > 1.1'. There is no way that a new versioning approach will be
> > understood by existing YANG tooling. That's an illusion.
> > 
> > /js
> > 
> > On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
> > > WG,
> > >
> > > Please help the YANG-versioning effort move forward by participating in 
> > > the
> > following poll:
> > >
> > >   - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login 
> > > required)
> > >
> > > Kent and Lou
> > >
> > 
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > 
> > --
> > Jürgen Schönwälder  Constructor 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

-- 
Jürgen Schönwälder  Constructor 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] Poll on YANG Versioning NBC Approach

[Jason Sterne (Nokia)]

Hi Jurgen,

We need this poll to set fundamental direction in the WG. Yes, there will still 
be discussion & debate around *either* option once we select one. But we need 
to agree on whether we're moving ahead by updating YANG 1.0/YANG 1.1 (without 
requiring any sort of new YANG version number) or if we as a WG are going to 
insist on only allowing this work to continue and exist in YANG modules marked 
with a new YANG version 1.2.

We need to put this part of the decision behind us and move onto the next set 
of discussions & issues.

Jason

> -Original Message-
> From: netmod  On Behalf Of Jürgen Schönwälder
> Sent: Tuesday, September 12, 2023 1:55 AM
> To: Kent Watsen 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> 
> 
> CAUTION: This is an external email. Please be very careful when clicking 
> links or
> opening attachments. See the URL nok.it/ext for additional information.
> 
> 
> 
> I disagree with the poll. There are important teachnigal differences
> behind the two options that this polls tries to hide.
> 
> Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> 1.1'. There is no way that a new versioning approach will be
> understood by existing YANG tooling. That's an illusion.
> 
> /js
> 
> On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
> > WG,
> >
> > Please help the YANG-versioning effort move forward by participating in the
> following poll:
> >
> >   - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login 
> > required)
> >
> > Kent and Lou
> >
> 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> --
> Jürgen Schönwälder  Constructor 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] Poll on YANG Versioning NBC Approach

[Jason Sterne (Nokia)]

Hi all,

I'd encourage anyone to remind themselves of some of the details around this 
issue before answering the poll.

Summary of options by the YANG Versioning weekly call group:
https://mailarchive.ietf.org/arch/msg/netmod/MSjLKSy7PwjaDkJdnwKREY9KCbc/

IETF 117 NETMOD meeting recording (YANG Versioning starts at 14 minutes in, 
also see results of the "Show of Hands"): IETF117-NETMOD-20230724-2000 
(meetecho.com)

Rgds,
Jason

From: netmod  On Behalf Of Kent Watsen
Sent: Monday, September 11, 2023 6:40 PM
To: netmod@ietf.org
Subject: [netmod] Poll on YANG Versioning NBC Approach


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


WG,

Please help the YANG-versioning effort move forward by participating in the 
following poll:

  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)

Kent and Lou

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

Re: [netmod] WG adoption call: draft-boucadair-netmod-rfc8407bis-02

[Adrian Farrel]

Hi Lou,

Yes, it is totally appropriate that we revisit this guidance. A lot has been
learned in the five years since 8407 and the long list of updates already in
this draft show that there is work to be done.

Adopt and work.

Cheers,
Adrian

-Original Message-
From: netmod  On Behalf Of Lou Berger
Sent: Monday, September 11, 2023 11:22 PM
To: NETMOD Group 
Cc: NetMod WG Chairs 
Subject: [netmod] WG adoption call: draft-boucadair-netmod-rfc8407bis-02

Hello,

This email begins a 2-week adoption poll for: 
https://datatracker.ietf.org/doc/draft-boucadair-netmod-rfc8407bis/

Please voice your support or technical objections to adoption on the
list by the end of the day (any time zone) Sept 25.

Thank you,
Lou (as Co-chair)

___
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