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

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

> Bert,
> 
> As the description of the notification says, the first object 
> (ifIndex) is the interface index of the TE link. This index 
> is an index to the lmpTeLinkTable.

Why do you not spell that out in the description clause, 
I think that will make that much clearer for novice readers

> The second object 
> (lmpDataLinkRemoteIfId) is the remote data link (not TE link) 
> interface identifier. It is the index to the lmpDataLinkTable 
> on the remote node.
> 
> There is no way to figure out TE link index from the remote 
> data link interface identifier OID and vice-versa.
> 
> Martin
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Monday, July 22, 2002 3:01 PM
> To: Martin Dubuc; Jing Qian
> Cc: ccamp@ops.ietf.org
> Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
> 
> 
> 
> > -----Original Message-----
> > From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com]
> > Sent: maandag 22 juli 2002 18:49
> > To: Wijnen, Bert (Bert); Jing Qian
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
> > 
> > 
> > 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.
> > 
> Is that not the same ifIndex as the one used to index into this
> table? If so then it is already part of the OID for 
> lmpDataLinkremotedIfId is it not? If not, then you may want to
> make that somewhat clearer... (or is it just me who does not
> see this right away????)
> 
> > 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.
> > 
> Thanks
> 
> Bert
> > 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
> > 
>