RE: Question in draft-ietf-ccamp-lmp-mib-03.txt

["Martin Dubuc" <Martin.Dubuc@meriton.com>]

Bert,

For the lmpDataLinkPropertyMismatch notification, the first object (ifIndex) is the interface index of the TE link and the lmpDataLinkRemoteIfId is the data link remote interface identifier. Both objects are required in this notification.

For the lmpTeLinkDegraded/lmpTeLinkNotDegraded notifications, I could use the lmpTeLinkOperStatus object instead of ifIndex. For the lmpTeLinkDegraded, ifIndex is good enough, but for lmpTeLinkNotDegraded, the lmpTeLinkOperStatus would bring some value. We probably want to have same object for both notifications. I'll make note of this change for the next version.

Martin

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Monday, July 22, 2002 11:05 AM
To: Jing Qian
Cc: Martin Dubuc; ccamp@ops.ietf.org
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt


Inline
> -----Original Message-----
> From: Jing Qian [mailto:jing.qian@alcatel.com]
> Sent: maandag 22 juli 2002 16:21
> To: Wijnen, Bert (Bert)
> Cc: martin.dubuc@meriton.com; ccamp@ops.ietf.org
> Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt
> 
> Did you mean OID is automatically as part of the trap message payload?

the lmpCcId is the INDEX for these objects itself, so that is
why it comes as part of the OID in the varbind for OperStatus and 
Adminstatus

> If in this case, why all the other trap still put the OID in 
> the OBJECT part?
> For example, in draft-ietf-ccamp-lmp-mib-03.txt:
>         lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
>            OBJECTS       { ifIndex,
>                                          lmpDataLinkRemoteIfId }

In the above case, the ifIndex indeed already is part of theOID
for the lmpDataLinkRemoteIfId, and so it is not needed.

>         lmpTeLinkDegraded NOTIFICATION-TYPE
>            OBJECTS       { ifIndex }
> 
In this one, at least some object seems to be needed in order
to indicate to the interface that has a problem. But possibly 
another object might make more sense.

Authors/WG... what do you think about this?

> Also, why need lmpCcOperStatus for lmpControlChannelUp and
> lmpControlChannelDown? The trap message name already define
> the lmpCcOperStatus.
> 
That is a valid question. I think sending the extra OperStatus
varbind does not really hurt, but it indeed seems to be
implied in the name of the NOTIFICATION

Bert