Subject: [netmod] Any implementation of ietf-snmp.yang RFC 7407

From: Balázs Lengyel <[email-masked]>
Date: Tue, 18 Dec 2018 14:57:12 +0000

Hello,

Does anyone know about implementations of the ietf-snmp YANG model?
As far as I could find none of the SW/vendors yumapro, tailf/confd, 
snmp-research, adventnet, netsnmp, snmp4j, Cisco, Huawei, Nokia, Juniper 
have implemented it.

regards Balazs

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Dec 2018 17:10:18 +0100 (CET)

Balázs Lengyel <[email-masked]> wrote:
> snmp-research, adventnet, netsnmp, snmp4j, Cisco, Huawei, Nokia,
> Juniper have implemented it.

We shave an implementation that isn't exactly the model in the RFC,
but close.  Did you ask b/c you have found some issue with the model?

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 18 Dec 2018 16:21:45 +0000

> but close.  Did you ask b/c you have found some issue with the model?

I asked, because I see so little uptake for the model, I am starting to 
wonder, if this is a dead RFC no one cares about, or whether it just 
takes time for people to implement it. Whether ONAP that requires this 
RFC really wants this, or they just listed all finalized YANG models 
sonetime earlier.

regards Balazs

---

From: tom petch <[email-masked]>
Date: Mon, 24 Dec 2018 16:51:01 +0000

Martin

The Acknowledgements for
draft-ietf-softwire-yang-13
thank you for your work on this I-D (on the IESG Telechat for 10th
January 2019) so can you tell me where my YANG is going wrong.

The module has
  augment "/if:interfaces/if:interface" {
    when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
and defines aplusp as a tunnel type in section 10.

A suggestion I made last October was to have a base for the three
protocols covered here - MAP-E, MAP-T, Lw406 - and then derive three
separate entities therefrom for the three protocols; I can see no
derivation.  In which case, when is

    when "derived-from(if:type, 'iana-tunnel-type:aplusp')";

going to be true?

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Dec 2018 13:08:36 +0100 (CET)

>     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";

Right; either they have to define derived identities as you suggested,
or this need to change to 'derived-from-or-self'.

/martin

---

From: tom petch <[email-masked]>
Date: Thu, 27 Dec 2018 15:06:01 +0000

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 27, 2018 12:08 PM

> or this need to change to 'derived-from-or-self'.

.. or drop the 'derived' altogether; if there is only 'aplusp', as at
present, then I see no need for 'derived' and inserting one
unnecessarily leaves scope for a future addition to be true when it is
not wanted.  I can see it either way.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Dec 2018 08:47:41 +0100

tom petch <[email-masked]> writes:

> ... or drop the 'derived' altogether; if there is only 'aplusp', as at

Do you mean writing something like

    when "if:type = 'iana-tunnel-type:aplusp'";

?

This is brittle and shouldn't be used because it is a plain string
equality test and the result depends (in XML representation) on the
prefix that is declared for the namespace URI of the iana-tunnel-type
module.

It is true that derived-from/derived-from-or-self leaves scope for
future additions. However, if ever an identity is defined that
is derived from 'iana-tunnel-type:aplusp', then it IMO makes sense only
if the properties of the latter are inherited, so the "when" test
should still be true (and the augment applicable).

Lada

>
> Tom Petch
>
>>
>> /martin
>>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: tom petch <[email-masked]>
Date: Fri, 28 Dec 2018 11:35:33 +0000

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
Sent: Friday, December 28, 2018 7:47 AM
> > From: "Martin Bjorklund" [email-masked]

Lada

Thanks for that; I did indeed have the string equality test in mind,
even though RFC8407 says otherwise.  I think that all this is too
complicated, for me if not for the authors of I-D coming out of the
Routing Area - I-D such as this one have already have several makeovers,
courtesy of such as Martin and I, and for this in its present form to be
on the next IESG Telechat - well, par for the course.

On a different tack, I was looking at teas-types and seeing
uses path-objective-function_config
Hang on, is underscore valid? Yes, but why use it? RFC8407 suggests do
not.
or
    type union {
        type string {  length 0; // empty string      }
        type string {  pattern ...
and thinking why?  With no length restriction on the pattern, what does
the complexity of a YANG union add?
or
  description  "Then index of the label restriction list entry."; }
    container label-start {
      must "not(../label-end/te-label/direction) or "
        + "not(te-label/direction) "
        + "or ../label-end/te-label/direction = te-label/direction" {
        error-message "label-start and label-end must have the same
direction.";
where the error message tells me what is going on (not the description)
but I wondered about the second 'not'  which I asssume is to cater for
 "(te-label/direction) "
not having a value.  All they want is
'start direction must = end direction'
but it seems you need to be a contortionist to get there.

I would appreciate any comment on this last - is there a simpler way of
doing it?   After which, I shall return to lurking.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Dec 2018 14:03:36 +0100

> complicated, for me if not for the authors of I-D coming out of the

I agree it is complicated. On the other hand, using the string equality for
identities can lead to mysterious failures.

> Hang on, is underscore valid? Yes, but why use it? RFC8407 suggests do

Maybe the use of the underscore has some meaning? I personally woudn't be so
strict regarding naming conventions, as long as it makes sense to the module
authors and users. And as Randy Presuhn recently explained, there may in fact be
no practical difference between RFC 2119 terms MAY and SHOULD in cases like
this.

> the complexity of a YANG union add?

It is either an empty string or a string matching the pattern. Of course, it
would be possible to make the pattern match an empty string.

> but it seems you need to be a contortionist to get there.

A simpler way to express this could be

    must "not(../label-end/te-label/direction != te-label/direction)"

The inequality test turns false if either of the terms doesn't exist.

Lada

---

From: tom petch <[email-masked]>
Date: Fri, 28 Dec 2018 15:37:58 +0000

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
Sent: Friday, December 28, 2018 1:03 PM

> > Sent: Friday, December 28, 2018 7:47 AM

<snip>

> The inequality test turns false if either of the terms doesn't exist.

Ah yes, thanks for that; I was missing the fact that non-existent terms
make the inequality false.

Tom Petch