Subject: [yang-doctors] Best way to use only part of iana-if-types.yang

From: Balazs Lengyel <[email-masked]>
Date: Fri, 12 Aug 2016 18:24:31 +0200

Hello,

Our nodes support only some of the iana interface types. How do we
indicate the correct subset. We want to create the subset on a
model level and not just reject the unsupported values. The CLI
is model driven and in the help it will offer  all  if-types, as
indicated by the model, to the user. We cannot offer an
interface type and later reject it.

- The best would be to have a
deviation indicating no support for the identity. Sadly YANG
does not allow that.

- We could put a "must" statement to check the identity value, but
the CLI-help might not notice it

- we could create a fake iana-if-types.yang
file that contains the if-types that we support, but that is
ugly

- we could change the type of the identityref typed leaf by
adding an additional base to it "supported-if-type" and add this
base to all if-types in iana-if-types.yang
that we do support. However this still leads to editing the iana-if-types.yang file.

- we could change the base of any
referencing identityref to "my-supported-interface-types", but
then the management system will not see this as a standard
solution

- something else?

What is the preferred solution?

regards Balazs

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Aug 2016 10:03:41 -0700

Hi,

This seems like a presentation layer issue that your NMS should handle.
It is generic to all identityrefs, although iana-if-type is the worst-case
example
that happens to show up on almost every server.

There have been protocol solutions proposed, which would be
a much smarter approach than altering the YANG data models.

Andy

On Fri, Aug 12, 2016 at 9:24 AM, Balazs Lengyel <[email-masked]
> wrote:

> indicate the correct subset. We want to create the subset on a model level
> and not just reject the unsupported values. The CLI is model driven and in
> the help it will offer  all  if-types, as indicated by the model, to the
> user. We cannot offer an interface type and later reject it.
>
> - The best would be to have a deviation indicating no support for the
> identity. Sadly YANG does not allow that.
>
> - We could put a "must" statement to check the identity value, but the
> CLI-help might not notice it
> - we could create a fake iana-if-types.yang file that contains the
> if-types that we support, but that is ugly
> - we could change the type of the identityref typed leaf by adding an
> additional base to it "supported-if-type" and add this base to all if-types
> in iana-if-types.yang that we do support. However this still leads to
> editing the iana-if-types.yang file.
> - we could change the base of any referencing identityref to
> "my-supported-interface-types", but then the management system will not
> see this as a standard solution
> - something else?
>
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
>

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 12 Aug 2016 19:08:08 +0200

Hello Andy,

I actually very much like the idea of providing a model that
really states what I support.

I also like the idea of a model driven CLI (without the need to
make many little presentation layer adjustments as they are
costly.)

What do you mean by protocol solutions?

IMHO it is a problem that deviations don't allow you to do a
number of things:

remove identities

change description statements

etc.

regards Balazs

On 2016-08-12 19:03, Andy Bierman
wrote:

Hi,

This seems like a presentation layer issue that your NMS
should handle.

It is generic to all identityrefs, although iana-if-type is
the worst-case example

Andy

On Fri, Aug 12, 2016 at 9:24 AM, Balazs
Lengyel <[email-masked]>
wrote:

Hello,

Our nodes support only some of the iana interface types. How do
we indicate the correct subset. We want to create the
subset on a model level and not just reject the
unsupported values. The CLI is model driven and in the
help it will offer  all  if-types, as indicated by the
model, to the user. We cannot offer an interface type
and later reject it.

- The best would be to
have a deviation indicating no support for the
identity. Sadly YANG does not allow that.

- We could put a "must" statement to check the identity
value, but the CLI-help might not notice it

- we could create a fake iana-if-types.yang
file that contains the if-types that we support, but
that is ugly

- we could change the type of the identityref typed
leaf by adding an additional base to it
"supported-if-type" and add this base to all if-types
in iana-if-types.yang
that we do support. However this still leads to
editing the iana-if-types.yang
file.

- we could change the base of
any referencing identityref to
"my-supported-interface-types", but then the
management system will not see this as a standard
solution

- something else?

regards Balazs

[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Aug 2016 10:15:03 -0700

On Fri, Aug 12, 2016 at 10:08 AM, Balazs Lengyel <
[email-masked]> wrote:

> Hello Andy,
>
> I actually very much like the idea of providing a model that really states
> what I support.
> I also like the idea of a model driven CLI (without the need to make many
> little presentation layer adjustments as they are costly.)
>
>

But the data model solution is more costly.
It also doesn't work because the YANG module is supposed to represent
the one and only API definition.  Deviations are the only way to alter
the data model to constrain instance documents.
This does not really work because different instances of interface type
accept different identities.

> What do you mean by protocol solutions?

Martin and I both had drafts I think.
You could define an RPC operation to return the allowed identities
for a specific identityref data node instance.

> IMHO it is a problem that deviations don't allow you to do a number of
> things:
>
>    - remove identities
>    - change description statements
>    - etc.
>
> regards Balazs
>
>
Andy

> On 2016-08-12 19:03, Andy Bierman wrote:
>
> Hi,
>
> On Fri, Aug 12, 2016 at 9:24 AM, Balazs Lengyel <
> [email-masked]> wrote:
>
>> Hello,
>>