Subject: Re: [YANG] Qs about keyref

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 1 Dec 2007 14:57:35 +0100

On Sat, Dec 01, 2007 at 12:27:21AM +0100, Martin Bjorklund wrote:
 
> OTOH, this problem came up when translating SNMP traps.  One problem
> there is the trap may look like this:
> 
>   OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
> 
> In this case, all three objects will be from the same ifEntry
> instance.  So the instance information is repeated 3 times (some may
> say 4).  But if we did this trap in YANG + leafref, we would
> explicitly specify that they come from the same ifEntry:
> 
>   leaf ifIndex {
>     type leafref {
>       path "/if:interface/if:ifEntry/if:ifIndex";
>     }
>   }
>   leaf ifAdminStatus {
>     type leafref {
>       path "/if:interface/if:ifEntry"
>          + "[ifIndex = $this/../ifIndex]/if:ifAdminStatus":
>     }
>   }
>   leaf ifOperStatus {
>     type leafref {
>       path "/if:interface/if:ifEntry"
>          + "[ifIndex = $this/../ifIndex]/if:ifOperStatus":
>     }
>   }

But we can't do that; SNMP does not require that the instances in a
notification are from the same row. And since there is not such rule
in the SMIv2, we have to provide full instance information for each
notification object, whether we like it or not. But that is all SMIv2
translation and of secondary importance. The question is how we would
achieve the same thing in plain YANG and then the above may work
except that it is terrible verbose (consider something which has a
more complex key).
   
> And an instance doc:
> 
>   <linkDown>
>     <ifIndex>2</ifIndex>
>     <ifAdminStatus>up</ifAdminStatus>
>     <ifOperStatus>down</ifOperStatus>
>   </linkdown>
> 
> 
> The YANG spec obviously isn't perfect... but it is better than the
> auto-generated one.
> 
> As an alternative, I was thinking that maybe we somehow could point
> out a list entry or container, and then just list the children we want
> to include in the notification.  This would be useful in notifications
> and rpc-replies.
> 
> Something like this (warning: just an idea)
> 
>   notification linkDown {
>     add-objects-from {
>       path "/if:interface/if:ifEntry";
>       include ifIndex;  // maybe the key is auto-added?  No...
>       include ifAdminStatus;
>       include ifOperStatus;
>       include ifExtra/ifFooBar; // add from a container
>     }
>   }
> 
> One problem is that the add-objects-from doesn't really work like the
> rest of the data definition statements in YANG...  And if you have
> nested lists it's a bit trickier...

But I think we need to think more along this line. In SMIng, we were
also referencing attributes to include in a notification rather than
defining new attributes that have magic types that somehow link to the
things in question. Perhaps we need something "inverse" to the augment
(link is not a good name):

notification linkDown {
    link "/if:interface/if:ifEntry" {
    	leaf ifIndex;
        leaf ifAdminStatus;
        leaf ifOperStatus;
    }
}

Something like this might also be handy to link parameters of RPCs to
things in the data tree...

/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/>

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 1 Dec 2007 11:21:28 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Martin Bjorklund" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, December 01, 2007 5:57 AM
> Subject: Re: [YANG] Qs about keyref
...
> except that it is terrible verbose (consider something which has a
...
> (link is not a good name):
...

Perhaps it would be helpful to step back a bit a think about what a
notification really is.  Though the SNMP syntax was clearly better for
implementation, the CMIP model captured the semantics a bit better.
A notification says that something interesting has happened to some
specific object(s), and carries helpful "interesting" attributes of the
relevant object(s), and perhaps some additional information about
the event itself.  The SNMP SMI forced this information to be glommed
together in an easy-to-implement but highly unnatural way.

In looking at how to do this in netconf, it might be helpful to remind
ourselves that the SNMP worldview (that everything is attributes and
that objects are merely synthesized from them) isn't the only one.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 1 Dec 2007 20:26:00 +0100

> that objects are merely synthesized from them) isn't the only one.

SMIng did associate events with objects (e.g. a linkDown would be an
event associated with an interface object) and then the protocol
mappings would specify how such events are mapped to notifications and
this mapping would also specify which attributes are being send as
part of the notification.

I am not sure, though, we will end up with the same approach in YANG.
Anyway, since SNMP's SMI is allows arbitrary data to go into a
notification, I think the mappings should not make any assumptions are
treat the SNMP notification varbinds as rather independent beings
(like SNMP treats them as independent beings, each one carrying its
own instance identifier).

With pure YANG notifications, we can hopefully do better but I fear
the fuzzyness of SNMP's SMI can be automagically be fixed.

/js