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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

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