Subject: Re: [Netmod-ver-dt] Problem statement about import by revision and early warning of removal

From: wangzitao <[email-masked]>
Date: Mon, 11 Jun 2018 02:33:36 +0000

Dear All,

I agree with Juergen that it should be solved by some simple way. And I also think that Rob’s concern make sense, letting reader easy aware the convention is an issue.
There may need to define some documentation/coding conventions and new “canonical order”, which can help reader/tools to retrieve.

Best Regards!
-Michael

-----邮件原件-----
发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Robert Wilton
发送时间: 2018年6月8日 21:44
收件人: Juergen Schoenwaelder <[email-masked]>
抄送: Mahesh Jethanandani <[email-masked]>; Balazs Lengyel <[email-masked]>; [email-masked]; Benoit Claise <bclaise=[email-masked]>
主题: Re: [Netmod-ver-dt] Problem statement about import by revision and early warning of removal

On 08/06/2018 12:39, Juergen Schoenwaelder wrote:
> On Fri, Jun 08, 2018 at 12:19:24PM +0100, Robert Wilton wrote:
>> Hi Mahesh,
>>
>> I think that Balazs is really trying to find an acceptable way to 
>> change the definition of YANG status: deprecated from "may or may not 
>> be supported" to "is still supported now, but it likely to be removed in a future revision".
>>
>> If something is deprecated then there are two useful additional 
>> pieces of information that could potentially be to provided to a client (if known):
>>
>> (i) When will the node likely be removed.
>> (ii) What is the alternative node(s) (if any).
>>
>> I guess that I see that this could be a "status" specific description 
>> statement that it meant to help provide lifecycle information to clients.
>> An alternative would be just to embed that information in the modules 
>> top level revision statement, but that may not work so well with 
>> tools like YANG catalog that are presenting information on a per schema node basis.
>>
> What speaks against simply adding a sentence to the regular 
> description statement? See RFC 8096 for an example how this was done 
> for obsolete MIB object definitions.
I would say that adding additional information to the data node description is a convention based approach that works now, but would rely on folks being aware of the convention.  However, I don't think that it is quite so friendly for tooling.  E.g. if diffing between two YANG modules, ideally want to report that the lifecycle has changed rather than the description of the data node.  If the YANG hood is up for other reasons then allowing a description statement under status seems like a small but potentially useful addition.

Thanks,
Rob
> /js

_______________________________________________
Netmod-ver-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: Robert Wilton <[email-masked]>
Date: Mon, 11 Jun 2018 17:48:50 +0100

Hi Michael,

> There may need to define some documentation/coding conventions and new “canonical order”, which can help reader/tools to retrieve.
If this is convention based, reusing the description statement of the 
data node itself, then it is hard to make robust tooling to handle this, 
since it would require parsing/interpretation of the data node 
description statement.

E.g. it wouldn't be possible to say that the last sentence of the 
description always relates to the data nodes 'status' because it might 
not be present at all.

You could define that the "status" part of the description always starts 
"status: " to make it easier for tooling to automatically parse, but 
what happens when someone forgets to do this, or there is a typo?  
Allowing the description statement under the status seems like a cleaner 
solution to me.

Thanks,
Rob

---

From: Ebben Aries <[email-masked]>
Date: Wed, 13 Jun 2018 18:26:52 -0700

On Jun 11 17:48 PM, Robert Wilton wrote:
> If this is convention based, reusing the description statement of the data
> node itself, then it is hard to make robust tooling to handle this, since it
> would require parsing/interpretation of the data node description statement.
> 
> description always relates to the data nodes 'status' because it might not
> be present at all.
> 
> "status: " to make it easier for tooling to automatically parse, but what
> happens when someone forgets to do this, or there is a typo?  Allowing the
> description statement under the status seems like a cleaner solution to me.

This now gets into specifying and mandating very specific delimeters to
ease parsing of string values in description statements.  As you mention
- not clean and could be problematic if one were to use a keyword
somewhere else in their description text.

A separate statement is much cleaner if we go down this path imo.

Note: Will be in flight in the am and will not be able to join the call
this week

> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod-2Dver-2Ddt&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=IMTlsK2GLF337uLVDvM980IXDMyrlavNObghtqrmAAU&s=yA6d6Rtk1R6K8w04XqmaWjuzXhbgk-zUA1zka8S-cl0&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod-2Dver-2Ddt&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=IMTlsK2GLF337uLVDvM980IXDMyrlavNObghtqrmAAU&s=yA6d6Rtk1R6K8w04XqmaWjuzXhbgk-zUA1zka8S-cl0&e=

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 14 Jun 2018 13:03:17 +0200

IMHO a YANG extension is a much cleaner solution for the status 
information then a documentation/coding convention. Conventions are easy 
to ignore/violate.

regards Balazs

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