Subject: [Netmod-ver-dt] Updated reqs draft

From: Joe Clarke <[email-masked]>
Date: Mon, 15 Oct 2018 10:09:04 -0400

I have made what I believe is all of the modifications to the reqs
draft.  I have pushed the XML to the develop branch in GH.  The text
diff can be found at:

https://tools.ietf.org/rfcdiff?url1=draft-verdt-netmod-yang-versioning-reqs-00&url2=https://namale.marcuscom.com:8443/~jclarke/draft-verdt-netmod-yang-versioning-reqs.txt

When we're satisfied, I'll merge to master and submit.

Note: each change had its own commit, so you can go back and read commit
messages if you'd like.

Joe

---

From: Robert Wilton <[email-masked]>
Date: Mon, 15 Oct 2018 15:29:48 +0100

Hi Joe,

All the changes look fine to me.  I wonder if we need to s/non backwards 
compatible/non-backwards-compatible/.  And equally s/backwards 
compatible/backwards-compatible/.

The requirements also sometimes refer to a backwards compatible change.  
Do you think that we should also add a definition for this for completeness?

Thanks,
Rob

On 15/10/2018 15:09, Joe Clarke wrote:
> _______________________________________________
> Netmod-ver-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt
> .
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 15 Oct 2018 14:40:12 +0000

We should s/backwards/backward/.

On 2018-10-15, 10:29 AM, "Netmod-ver-dt on behalf of Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Joe,

    
    Thanks,
    Rob

---

From: Robert Wilton <[email-masked]>
Date: Mon, 15 Oct 2018 15:42:57 +0100

> We should s/backwards/backward/.
It looks like the whole doc has just been converted the other way ;-)

Rob

---

From: Joe Clarke <[email-masked]>
Date: Mon, 15 Oct 2018 10:58:45 -0400

> compatible/backwards-compatible/.

I did this to be consistent with the terminology we define.

> Do you think that we should also add a definition for this for

I was thinking about that.  But the best I could come up with was those
changes that do adhere to Section 11 of 7950.  That seemed kind of
obvious to me.

Joe

---

From: Joe Clarke <[email-masked]>
Date: Mon, 15 Oct 2018 10:59:16 -0400

> We should s/backwards/backward/.

Thought about that, too.  Again, I stayed consistent with Jason's term,
but I am happy to change to meet the group's consensus.

Joe

---

From: Robert Wilton <[email-masked]>
Date: Mon, 15 Oct 2018 16:05:53 +0100

> but I am happy to change to meet the group's consensus.
OK.  I'm not sure that I care too much, but I notice that semver.org 
uses "backwards compatible".

Another reference claims that "backwards compatible" is British English, 
where as "backward compatible" is an Americanism ;-)

Rob

---

From: Robert Wilton <[email-masked]>
Date: Mon, 15 Oct 2018 16:07:07 +0100

> I did this to be consistent with the terminology we define.
OK.  Unless you have updated it again, I think that I may have spotted 
that both forms were being used in the doc.

> changes that do adhere to Section 11 of 7950.  That seemed kind of
Fine with me.

Thanks,
Rob

---

From: Joe Clarke <[email-masked]>
Date: Mon, 15 Oct 2018 11:20:43 -0400

> Do you think that we should also add a definition for this for

I found some other instances and consistified them, too.  New txt diff
is up at the same URL.

Joe

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 15 Oct 2018 15:31:40 +0000

I actually thought backward was the proper term but looks like both backward and backwards are commonly used. So lets' stick to 1, and if it's backwards, I won't say anything more on the topic.

But what about "compatible backwards" which is Canadian English (

On 2018-10-15, 11:05 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]> wrote:

    
    
    Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 15 Oct 2018 15:39:54 +0000

There are instances of  "backwards compatible" left in sections 2.2, 2.3 and 5.

On 2018-10-15, 11:20 AM, "Netmod-ver-dt on behalf of Joe Clarke (jclarke)" <[email-masked] on behalf of [email-masked]> wrote:

    
    Joe

---

From: Joe Clarke <[email-masked]>
Date: Mon, 15 Oct 2018 11:47:34 -0400

> There are instances of  "backwards compatible" left in sections 2.2, 2.3 and 5.

So I did everything as "backwards" (that's what you see now).  Does the
group want me to revert all to "backward"?

Joe

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 15 Oct 2018 15:52:54 +0000

I'm fine with backwards, but I was expecting backwards-compatible everywhere (not backwards compatible).

On 2018-10-15, 11:47 AM, "Netmod-ver-dt on behalf of Joe Clarke (jclarke)" <[email-masked] on behalf of [email-masked]> wrote:

    
    Joe

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 15 Oct 2018 16:03:52 +0000

Is backward/backwards really so important?

Balazs

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

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 15 Oct 2018 16:12:16 +0000

No, but I want to be consistent.

Joe

PGP Key : http://www.marcuscom.com/pgp.asc

> On Oct 15, 2018, at 12:05, Balázs Lengyel <[email-masked]> wrote:
>

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 15 Oct 2018 16:14:24 +0000

Hello,

I am a bit worried about 1.2. I know Jurgen will kill me for this, but 
we want to be able to keep some of the nbc changed items also on the 
same path.

E.g. if I have a script that lists timer values and then the range of 
the timer values is decreased (nbc) I don't want to be forced to update 
that script. It really should be the clients decision whether the nbc 
change actually impacts it or not. We should not force the client to be 
updated.

regards Balazs

---

From: Robert Wilton <[email-masked]>
Date: Mon, 15 Oct 2018 17:28:51 +0100

Hi Balazs,

On 15/10/2018 17:14, Balázs Lengyel wrote:
> the timer values is decreased (nbc) I don't want to be forced to 
> update that script. It really should be the clients decision whether 
> the nbc change actually impacts it or not. We should not force the 
> client to be updated.
I don't think that 1.2 prevents this.

My reading is that if the client does not use the "timer values" leaf 
then it MUST be able to continue to work unchanged.  If it is using 
"timer values" then it using a nbc changed path and Req 1.2 does not apply.

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 15 Oct 2018 17:55:12 +0000

Hi Joe,

Looks good. Nits/suggestions/questions on the text (doesn't impact content):
- Section 2.4 uses term "modeler". I don't have a good suggestion: "YANG module authors", "YANG module editors"...
- Section 2.5 s/If MOD-A is developed in a backwards-compatible/If MOD-A is updated in a backwards-compatible/
- Use of term "client", should that be in terminology section? Related to this, section 2.4  has "A Management system, SDN controller, or ....", why not use "client"?

Regards,
Reshad.

On 2018-10-15, 10:09 AM, "Netmod-ver-dt on behalf of Joe Clarke (jclarke)" <[email-masked] on behalf of [email-masked]> wrote:

    

    Joe

---

From: Joe Clarke <[email-masked]>
Date: Mon, 15 Oct 2018 14:36:33 -0400

> - Section 2.4 uses term "modeler". I don't have a good suggestion: "YANG module authors", "YANG module editors"...

Changed to YANG module author.

> - Section 2.5 s/If MOD-A is developed in a backwards-compatible/If MOD-A is updated in a backwards-compatible/

Fixed (two instances).

> - Use of term "client", should that be in terminology section? Related to this, section 2.4  has "A Management system, SDN controller, or ....", why not use "client"?

I don't think we need to define client, personally.  And in this case, I
wouldn't use client because in this context we're talking not just about
clients but about people (i.e., users) themselves.

Perhaps this could read a NETCONF/RESTCONF client or any other user...

What does the team think?

Joe

---

From: Joe Clarke <[email-masked]>
Date: Mon, 15 Oct 2018 14:40:55 -0400

FYI, latest diff text is up.

Still to do is to normalize all backwards compatible to
backwards-compatible.

Joe

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 16 Oct 2018 12:20:00 +0000

All good with me.

On 2018-10-15, 2:41 PM, "Joe Clarke (jclarke)" <[email-masked]> wrote:

    
    Joe

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Oct 2018 08:08:24 +0000

Would it be great to replace " Non-backwards-compatible" with abbreviation "NBC".
The cosmetic change to address this is:
OLD TEXT
"
Section 3
Non-backwards-compatible: In the context of this document, the  
          term 'non-backwards-compatible' refers to a change or set of  
          changes between two YANG module revisions that do not adhere to  
          the list of allowable changes specified in Section 11 "Updating a  
          Module" of [RFC7950], with the following additional clarification:  
      
          *  Any addition of, or change to, a "status" statement that allows  
             a server to remove support for a schema node is considerd a  
             non-backwards-compatible change
"
NEW TEXT:
"
Non-backwards-compatible(NBC): In the context of this document, the  
          term 'non-backwards-compatible' refers to a change or set of  
          changes between two YANG module revisions that do not adhere to  
          the list of allowable changes specified in Section 11 "Updating a  
          Module" of [RFC7950], with the following additional clarification:  
      
          *  Any addition of, or change to, a "status" statement that allows  
             a server to remove support for a schema node is considered a  
             non-backwards-compatible change
"
One typo in the definition of "Non-backwrads-compatible" :
s/considerd/considered

-Qin
-----邮件原件-----
发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Joe Clarke
发送时间: 2018年10月16日 2:41
收件人: Reshad Rahman (rrahman); [email-masked]
主题: Re: [Netmod-ver-dt] Updated reqs draft

Still to do is to normalize all backwards compatible to backwards-compatible.

Joe

On 10/15/18 14:36, Joe Clarke wrote:
>> - Section 2.5 s/If MOD-A is developed in a backwards-compatible/If 
>> MOD-A is updated in a backwards-compatible/
> 
> Fixed (two instances).
> 
> I don't think we need to define client, personally.  And in this case, 
> I wouldn't use client because in this context we're talking not just 
> about clients but about people (i.e., users) themselves.
> 
>> https://tools.ietf.org/rfcdiff?url1=draft-verdt-netmod-yang-versionin
>> g-reqs-00&url2=https://namale.marcuscom.com:8443/~jclarke/draft-verdt
>> -netmod-yang-versioning-reqs.txt
>>

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 17 Oct 2018 08:57:11 +0000

YESSSSSS!!!!!   I don't want 24 characters instead of 3.
Balazs

---

From: Joe Clarke <[email-masked]>
Date: Wed, 17 Oct 2018 08:44:52 -0400

> The cosmetic change to address this is:

Given that we've been using this in internal threads, I'm inclined to
make this change.  Any objections?

> One typo in the definition of "Non-backwrads-compatible" :

Thanks, Qin.  Will fix.

Joe

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 17 Oct 2018 12:46:02 +0000

None from me.

On 2018-10-17, 8:44 AM, "Joe Clarke (jclarke)" <[email-masked]> wrote:

    
    
    Thanks, Qin.  Will fix.
    
    Joe

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 17 Oct 2018 13:47:01 +0000

OK with me.

> -----Original Message-----
> From: Netmod-ver-dt <[email-masked]> On Behalf Of Balázs
> Lengyel
> Sent: Wednesday, October 17, 2018 4:57 AM
> To: Qin Wu <[email-masked]>; Joe Clarke <[email-masked]>; Reshad
> Rahman (rrahman) <[email-masked]>; [email-masked]
> Subject: Re: [Netmod-ver-dt] Updated reqs draft - use abbreviations
> 
> >>> - Section 2.4 uses term "modeler". I don't have a good suggestion: "YANG
> module authors", "YANG module editors"...
> >>> - Use of term "client", should that be in terminology section? Related to
> this, section 2.4  has "A Management system, SDN controller, or ....", why not
> use "client"?
> >>> On 2018-10-15, 10:09 AM, "Netmod-ver-dt on behalf of Joe Clarke (jclarke)"
> <[email-masked] on behalf of [email-masked]> wrote:
> >>>