Subject: [YANG] Re: analysis of YANG vs. RELAX NG

From: Balazs Lengyel <[email-masked]>
Date: Thu, 13 Dec 2007 17:58:35 +0100

Hello Chris, Yang-Gang,
I think this is an interesting idea. It could also be used for things that are so tricky that 
only vendor support personnel should use it. I will add it to the draft if no objections.
Balazs

Chris Newman wrote:
> [off list since this is off topic]
> 
> Balazs Lengyel wrote on 11/29/07 10:56 +0100:
>> - a flag stating if a part of configuration is current, deprecated, 
>> obsolete
> 
> For the XML configuration software I'm working on for Sun's mail server 
> software, we have an additional state -- "restricted" that means roughly 
> "setting this option without permission of product support renders the 
> device into an unsupported operation mode".  Useful for those kludges 
> demanded by one big customer, for features that are present in the code 
> but are alpha quality, or for standards-violating features that 
> customers sometimes demand.  You might want to think about the cost of 
> including such a feature now vs. adding it later if it's needed.
> 
>                - Chris
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

_______________________________________________
YANG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/yang

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Dec 2007 18:09:17 +0100

On Thu, Dec 13, 2007 at 05:58:35PM +0100, Balazs Lengyel wrote:

> I think this is an interesting idea. It could also be used for
> things that are so tricky that only vendor support personnel should
> use it. I will add it to the draft if no objections.

I am confused. Usually, "current", "deprecated", "obsolete" refers to
the status of a definition and that is not the same and in fact
different from "harmful" or "pointless". Even a "harmful" definition
can be "current", "deprecated", or "obsolete".

Something that should not be touched by average users simply should be
properly protected by access control rules, no?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 14 Dec 2007 16:26:45 +0100

Hello Jurgen,
You are right the "restricted" marking is a separate issue from the status, but still a valid 
use case.

Access control is usually set by the customer, so I don't think it is a good way to restrict 
the customer itself from using specific features. If we would be looking for a restriction 
like: "Only expert operators are allowed to use this" I would agree with your proposal to use 
normal access control.

However we are looking more for a "No employee of the customer is allowed to used this" 
restriction. (Only for vendor support, or only for specific customers).

I think hidden data plays a somewhat similar role in the Tailf implementation.
regards Balazs

PS: In Ericsson we love having "harmful" features. It is called job security for customer 
support :-)

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Dec 2007 07:52:29 -0800

Balazs Lengyel wrote:
> Hello Jurgen,
> You are right the "restricted" marking is a separate issue from the 
> status, but still a valid use case.
> 

I think Juergen means you are mixing apples and oranges
by putting 'restricted' in with current/deprecated/obsolete.

This is yet another proprietary data model property,
such as 'hidden', 'help', 'sort-order', etc.

If a property is common enough, then it should be included
in the standard, instead of a vendor extension.
In this case, the 'restricted' status has no impact
whatsoever on the NETCONF protocol.  IMO, NETCONF does
not need any extensions to warn customers that <edit-config>
on specific data will void their warranty, because the data is restricted.

I prefer a coherent, comprehensive, standard access control model instead.

Andy

> Access control is usually set by the customer, so I don't think it is a 
> good way to restrict the customer itself from using specific features. 
> If we would be looking for a restriction like: "Only expert operators 
> are allowed to use this" I would agree with your proposal to use normal 
> access control.
> 
> However we are looking more for a "No employee of the customer is 
> allowed to used this" restriction. (Only for vendor support, or only for 
> specific customers).
> 
> PS: In Ericsson we love having "harmful" features. It is called job 
> security for customer support :-)
>