Subject: Re: [Netmod-ver-dt] [netmod] adoption poll for yang-versioning-reqs-02

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 17 Mar 2019 16:39:29 -0700

I wanted to respond to the call for support of the document, but as contributor have always wondered whether it makes sense. As chair I have always put lesser weightage to contributors responding to calls for support of the document. After all we would not be working on the document if we did not like the idea of publishing it.

Based on the responses we have received (which by the way is all from contributors), I wonder if we need to get support from the larger community on the draft.

Just my 2 cents.

> On Mar 17, 2019, at 2:23 PM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 
> As contributor, I support adoption of this document by the WG.
>  
> Regards,
> Reshad.
>  
> From: netmod <[email-masked] <mailto:[email-masked]>> on behalf of Kent Watsen <[email-masked] <mailto:[email-masked]>>
> Date: Wednesday, March 13, 2019 at 4:22 PM
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Subject: [netmod] adoption poll for yang-versioning-reqs-02
>  
> Seeing as how we all need to read this draft anyways, in preparation for our meeting in Prague, it seems like a good time for this poll.  Thusly, this email begins a 1-week adoption poll for:
>  
>     https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 <https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02>
>  
> Please voice your support or objections before March 20.
>  
> Note that this draft defines *requirements* and its intended status is "Informational."   I believe that it is good for WGs to formalize requirements, even taking such drafts thru Last Call, in order to ensure consensus on the requirements.  This is the "adoption" call, to ascertain if the WG agrees with that statement; if adopted, a separate "last call" will be issued to ensure to correctness of the draft's content.
>  
> Kent (and Lou and Joel)
>  
>  
> _______________________________________________
> netmod mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 18 Mar 2019 09:14:37 +0100

Mahesh,
> I wanted to respond to the call for support of the document, but as 
> contributor have always wondered whether it makes sense. As chair I 
> have always put lesser weightage to contributors responding to calls 
> for support of the document. After all we would not be working on the 
> document if we did not like the idea of publishing it.
>
> Based on the responses we have received (which by the way is all from 
> contributors), I wonder if we need to get support from the larger 
> community on the draft.
Don't you believe you had enough discussion on this topic on the list 
and during the meetings?
Don't you believe that, if you the WG chairs created a design team, it's 
because there is a problem to be solved?

Regards, Benoit
>
> Just my 2 cents.
>
>> On Mar 17, 2019, at 2:23 PM, Reshad Rahman (rrahman) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> *From:*netmod <[email-masked] 
>> <mailto:[email-masked]>> on behalf of Kent Watsen 
>> <[email-masked] <mailto:[email-masked]>>
>> *Date:*Wednesday, March 13, 2019 at 4:22 PM
>> *To:*"[email-masked] <mailto:[email-masked]>" <[email-masked] 
>> <mailto:[email-masked]>>
>> *Subject:*[netmod] adoption poll for yang-versioning-reqs-02
>> Seeing as how we all need to read this draft anyways, in preparation 
>> for our meeting in Prague, it seems like a good time for this poll. 
>>  Thusly, this email begins a 1-week adoption poll for:
>> https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02
>> Note that this draft defines *requirements* and its intended status 
>> is "Informational."   I believe that it is good for WGs to formalize 
>> requirements, even taking such drafts thru Last Call, in order to 
>> ensure consensus on the requirements.  This is the "adoption" call, 
>> to ascertain if the WG agrees with that statement; if adopted, a 
>> separate "last call" will be issued to ensure to correctness of the 
>> draft's content.
>> Kent (and Lou and Joel)
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
> Netmod-ver-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 18 Mar 2019 06:40:54 -0700

Hi Benoit,

> On Mar 18, 2019, at 1:14 AM, Benoit Claise <[email-masked]> wrote:
> 
> Mahesh,
> Don't you believe you had enough discussion on this topic on the list and during the meetings?
> Don't you believe that, if you the WG chairs created a design team, it's because there is a problem to be solved?

I think you misunderstand. I am not disagreeing that we got here because the WG wanted us to work on it. But should that support not be reflected by folks other than the contributors to these documents?

>>> From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
>>> To: "[email-masked]" <[email-masked]>
>>> [email-masked]

---

From: Benoit Claise <[email-masked]>
Date: Mon, 18 Mar 2019 15:13:34 +0100

Hi Mahesh,
> Hi Benoit,
>
> On Mar 18, 2019, at 1:14 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Mahesh,
>>> for support of the document. After all we would not be working on 
>>> the document if we did not like the idea of publishing it.
>>>
>>> Based on the responses we have received (which by the way is all 
>>> from contributors), I wonder if we need to get support from the 
>>> larger community on the draft.
>> Don't you believe that, if you the WG chairs created a design team, 
>> it's because there is a problem to be solved?
>
> I think you misunderstand. I am not disagreeing that we got here 
> because the WG wanted us to work on it. But should that support not be 
> reflected by folks other than the contributors to these documents?
I think you misunderstand my point: Let's get things done instead of 
adding process!

Regards, Benoit
>>>> Seeing as how we all need to read this draft anyways, in 
>>>> preparation for our meeting in Prague, it seems like a good time 
>>>> for this poll.  Thusly, this email begins a 1-week adoption poll for:
>>>> is "Informational."   I believe that it is good for WGs to 
>>>> formalize requirements, even taking such drafts thru Last Call, in 
>>>> order to ensure consensus on the requirements.  This is the 
>>>> "adoption" call, to ascertain if the WG agrees with that statement; 
>>>> if adopted, a separate "last call" will be issued to ensure to 
>>>> correctness of the draft's content.
>>>> Kent (and Lou and Joel)

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 18 Mar 2019 08:03:16 -0700

> On Mar 18, 2019, at 7:13 AM, Benoit Claise <[email-masked]> wrote:
> 
> Hi Mahesh,
>> Hi Benoit,
>> 
> I think you misunderstand my point: Let's get things done instead of adding process!

Fair enough. If the NETMOD chairs find consensus based on the inputs they have received, all the better!

Cheers.
(Speaking as contributor)

---

From: Kent Watsen <[email-masked]>
Date: Mon, 18 Mar 2019 16:09:07 +0000

I haven’t discussed with my co-chairs yet, but my going-in assumption is that the draft is adopted, unless an valid objection arises.  The poll is just a formality.  

As I wrote in the adoption call message, I think that it is *good* for WGs to have formal consensus for requirements.  To this end, I also support doing a Last Call on the draft. 

The only thing I’m unsure of is if it’s worth publishing as an RFC, or if it’s better expiring like opstate-reqs. 

The answer only lies in its historical value as, regardless that outcome, we will standardize the same versioning solution.  That is, the value seems to be only for us and only for now.  right?

That said, I have no real objection to publishing it.  I’m only trying to be sensitive to the IESG/Editor time. 

K.  // as a co-chair

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Mar 2019 17:55:26 +0100

> That said, I have no real objection to publishing it.  I’m only trying to be sensitive to the IESG/Editor time. 

I do see value in documenting which problems were identified and
(subsequently) solved. Sometimes it is useful to learn from the
past. I am not a fan of requiring WGs to write requirement documents
(in particular if these requirement exercises are intended to select
between competing proposals - an entire waste of time to resolve such
conflicts with requirement documents) but here we did write one and
then not publishing it as RFC seems a bit weird from my perspective.

Yes, we save some process steps. But it would be a pity if we stop
publishing the requirements because our processes got so heavy weight
that we stop publishing meaningful documents.

/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/>

---

From: Lou Berger <[email-masked]>
Date: Fri, 22 Mar 2019 15:07:39 -0400

Hi,

Thank you all for the good input on this thread.

With the understanding that a 00 working group document is a starting 
point for the working group rather than a document that is ready for 
last call - we believe there is sufficient support to adopt this 
document as a starting point for the requirements we wish to address on 
this topic.

It is clear that there is still work to be done on this document before 
we can declare consensus on it and, not surprisingly, that there is more 
work to be done on the solution.

Authors,

Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 
with the only change being the name and publication date.  The -01 
version should focus on resolving issues raised during adoption.  Of 
course the document is subject to normal WG input and processing.

Please note the 'file' name change -this is to indicate that the 
requirements are not presupposing a specific solution. It is also 
consistent with how versioning is defined within the document currently.

Note: we would like to try to continue the list discussion in next 
week's session and ask the Authors/DT to summarize issues raised during 
the adoption call and lead a discussion to help resolve these issues.

Thank you,

Lou (and Kent and Joel)

On 3/13/2019 4:22 PM, Kent Watsen wrote:
> Note that this draft defines *requirements* and its intended status is 
> "Informational."   I believe that it is good for WGs to formalize 
> ensure consensus on the requirements.  This is the "adoption" call, to 
> ascertain if the WG agrees with that statement; if adopted, a separate 
> "last call" will be issued to ensure to correctness of the draft's 
> content.
>
> Kent (and Lou and Joel)
>
>
>

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 24 Mar 2019 11:39:06 -0700

> On Mar 22, 2019, at 12:07, Lou Berger <[email-masked]> wrote:
> 
> Hi,
> 
> With the understanding that a 00 working group document is a starting point for the working group rather than a document that is ready for last call - we believe there is sufficient support to adopt this document as a starting point for the requirements we wish to address on this topic.
> 
> It is clear that there is still work to be done on this document before we can declare consensus on it and, not surprisingly, that there is more work to be done on the solution.
> 
> Authors, 
> 
> Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 with the only change being the name and publication date.  The -01 version should focus on resolving issues raised during adoption.  Of course the document is subject to normal WG input and processing.
> 
> Please note the 'file' name change -this is to indicate that the requirements are not presupposing a specific solution. It is also consistent with how versioning is defined within the document currently.
> 
> Note: we would like to try to continue the list discussion in next week's session and ask the Authors/DT to summarize issues raised during the adoption call and lead a discussion to help resolve these issues.
> 
I think this meeting is great opportunity to decide what steps need to be taken to advance the document within the working group.

Martin specifically objects to the presence of of Non-Backward-Compatible changes. 

Many modules outside the IETF are already incompatible with roc 7950 yang 1.1 revision rules. So that cat may be out of the bag at least with respect to the real world. the question remains what to do about that?

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Mar 2019 13:05:21 -0700

On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli <[email-masked]> wrote:

> point for the working group rather than a document that is ready for last
> call - we believe there is sufficient support to adopt this document as a
> starting point for the requirements we wish to address on this topic.
>
> It is clear that there is still work to be done on this document before we
> can declare consensus on it and, not surprisingly, that there is more work
> to be done on the solution.
>
> Authors,
>
> with the only change being the name and publication date.  The -01 version
> should focus on resolving issues raised during adoption.  Of course the
> document is subject to normal WG input and processing.
>
> Note: we would like to try to continue the list discussion in next week's
> session and ask the Authors/DT to summarize issues raised during the
> adoption call and lead a discussion to help resolve these issues.
>
> I think this meeting is great opportunity to decide what steps need to be
> taken to advance the document within the working group.
>
> Many modules outside the IETF are already incompatible with roc 7950 yang
> 1.1 revision rules. So that cat may be out of the bag at least with respect
> to the real world. the question remains what to do about that?
>
>

I do not look at the problem as allowing NBC so much as making it clear to
toolmakers what is going on,
like a deviation to the versioning rules.

BTW, I do not support adoption of the requirements document at all.
I support the work on versioning as part of the charter, and I am happy to
accept the design team solution draft as the starting point, and just work
on a solution.

But I think the solution is a bit flawed.

1) extensions are optional and problematic since they can be revisioned
without changing
    the language version; the solution needs to use new YANG 1.2 statements
instead of extensions

2) the version string does not have to contain all the NBC semantics.
The solution draft does not show modified semver.
It should be done differently than overloading the version string;

Let's say a fork is done on 1.3.0.

         revision 2017-07-30 {
           description "Added leaf foo-64";
           semver:module-version "1.3.0";
         }

start with a legal change, just not at the HEAD

         revision 2019-01-10 {
           description "Added leaf bar-64";
           semver:module-version "1.3.1";
         }

then later, an NBC change

        revision 2019-02-10 {
           description "Changed leaf bar-64 default-stmt";
           semver:module-version "1.3.2";
           semver:nbc-change;

         }

then later, a legal change

        revision 2019-03-10 {
           description "Added leaf baz-64";
           semver:module-version "1.3.3";

         }

This is a form of an inline deviation-stmt.
The YANG update rules are not changing. They are just not being followed.

The NBC info belongs in the revision-stmt, not overloading the version string.
Not every major revision will mean NBC changes anyway.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 24 Mar 2019 21:56:35 +0100 (CET)

>            semver:module-version "1.3.3";

+1  I have suggested something similar.

> The YANG update rules are not changing. They are just not being followed.

Right!

> The NBC info belongs in the revision-stmt, not overloading the version string.

Agreed.

> Not every major revision will mean NBC changes anyway.

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 25 Mar 2019 11:22:28 +0000

On 2019. 03. 24. 21:05, Andy Bierman
wrote:

On Sun, Mar 24, 2019 at
11:39 AM Joel Jaeggli <[email-masked]> wrote:

On Mar 22, 2019, at 12:07, Lou Berger <[email-masked]>
wrote:

Hi,

Thank you all for the good input on this
thread.

With the understanding that a 00 working group
document is a starting point for the working
group rather than a document that is ready for
last call - we believe there is sufficient
support to adopt this document as a starting
point for the requirements we wish to address on
this topic.

It is clear that there is still work to be done
on this document before we can declare consensus
on it and, not surprisingly, that there is more
work to be done on the solution.

Authors,

Please resubmit this document as
draft-ietf-netmod-yang-revision-reqs-00 with the
only change being the name and publication
date.  The -01 version should focus on resolving
issues raised during adoption.  Of course the
document is subject to normal WG input and
processing.

Please note the 'file' name change -this is to
indicate that the requirements are not
presupposing a specific solution. It is also
consistent with how versioning is defined within
the document currently.

Note: we would like to try to continue the list
discussion in next week's session and ask the
Authors/DT to summarize issues raised during the
adoption call and lead a discussion to help
resolve these issues.

I think this meeting is great opportunity to decide
what steps need to be taken to advance the document
within the working group.

Martin specifically objects to the presence of of
Non-Backward-Compatible changes.

Many modules outside the IETF are already
incompatible with roc 7950 yang 1.1 revision rules. So
that cat may be out of the bag at least with respect
to the real world. the question remains what to do
about that?

I do not look at the problem as allowing NBC so much as
making it clear to toolmakers what is going on,

BTW, I do not support adoption of the requirements
document at all.

I support the work on versioning as part of the charter,
and I am happy to

accept the design team solution draft as the starting
point, and just work on a solution.

1) extensions are optional and problematic since they can
be revisioned without changing

the language version; the solution needs to use new
YANG 1.2 statements instead of extensions

2) the version string does not have to contain all the
NBC semantics.

It should be done differently than overloading the
version string;

Let's say a fork is done on 1..3.0.

revision 2017-07-30 {

revision 2019-01-10 {

revision 2019-02-10 {

}

revision 2019-03-10 {

}

Andy

BALAZS: This would not work. Lets say we have 3 versions of a model
1, 2 and 3.

Between 1->2 there is an NB C change (non-backward compatible.

Between 2->3 there is a BC change.

We have a server that only implements ver-3. As the last change
was backward compatible ver-3 does not contain semver:nbc-change;

So if the client-A used ver-2 previously it will get the correct
information: change is BC

However if the client-B used ver-1 previously it will get
INCORRECT information.

If you say that the semver:nbc-change;is sticky and ver-3
contains semver:nbc-change; client-A gets wrong
information, it believes the change is NBC while it was BC.

The problem is that the server does not know which is the
"previous" model version for the client, and backwards
compatibility info is needed between the two model-versions the
client is using.

If we connect compatibility to the version number as we propose
this problem is solved.

regards Balazs

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]