Subject: RE: Atommib WG meeting summary

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 5 Aug 2004 14:05:47 -0400

Hi AToMMIBer,

If you are interested in the IMA MIB as a new work item or revising/advancing the existing MIBs, please show your interest and have action soon. Otherwise the WG will be concluded as noted by the AD.

In the case of advancing the existing MIBs, more implementation feedbacks are needed.

Regards,
Kam

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Thursday, August 05, 2004 1:28 PM
> To: Lam, Hing-Kam (Kam); [email-masked]'
> Cc: 'Faye Ly'; 'David Kessens (E-mail)'
> Subject: RE: Atommib WG meeting summary
> 
> 
> Thanks for the summary/report.
> 
> I think it is important to also include in the report that we only
> had 4 people showing up (including one of the WG chairs and the AD).
> Participation/interest seems to have come down to virtually none.
> 
> So (as I discussed with the WG chairs), this seems to indicate to me
> it is time to wrapup and close the WG as Kam expressed in his last
> para.
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Lam, Hing-Kam (Kam) 
> > Sent: woensdag 4 augustus 2004 20:44
> > To: Wijnen, Bert (Bert); Wijnen, Bert (Bert); 'David 
> Kessens (E-mail)'
> > Cc: 'Faye Ly'; [email-masked]'
> > Subject: Atommib WG meeting summary
> > 
> > 
> > Hi -
> > 
> > Here's the summary of the AToM MIB WG session:
> > 
> > The atommib working group met for one session on Tuesday 
> > afternoon at the San Diego IETF-60th meeting.  
> > 
> > The WG discussed the status of the implementation feedbacks 
> > and the IMA MIB Internet Draft.
> > 
> > Implementation feedback had been requested long time ago for 
> > the following PS: RFC2494 (DS0), RFC2495 (DS1/DS2), RFC2496 
> > (DS3), RFC2512 (ATM acct), RFC2513 (collection), RFC2514 (ATM 
> > TC), and RFC2515 (ATM). The received implementation feedbacks 
> > are not sufficient for some of the objects in order to 
> > advance any of the MIB modules as full modules without 
> > deprecating those objects.
> >  
> > For RFC2495 and RFC2496, it was suggested to leave them alone 
> > because both MIBs will be obsoleted once RFC2495bis and 
> > RFC2496bis are published. For the other MIBs, it was 
> > suggested to make another request to the list. If no 
> > additional feedback (even in the form of MIB walk) within 
> > couple weeks, the work items will be dropped from the 
> milestone list.
> > It was noted that there might be several IETF MIB modules 
> > that reference the RFC2514 TCs. If that is the case, that 
> > should be included in the report and may be able to advance 
> > RFC2514. Otherwiese it is still worth to submit the available 
> > implementation feedback of RFC2514 to IESG for information 
> to others.
> > 
> > The IMA MIB would require rechartering. However, unless there 
> > is enough interest from the list, the IMA MIB will not be a 
> > new WG work item. Besides, the new MIB should be rewritten as 
> > a supplement MIB to the ATM Forum IMA MIB and should not copy 
> > the ATM Forum IMA MIB objects as currently done in the I-D. 
> > An alternative will be to give input to ATMF for them to 
> > extend the IMA MIB.
> > 
> > In summary, the existing WG milestones are either done (e.g., 
> > RFC2495, RFC2496) or should be dropped (e.g., RFC 2515) due 
> > to lack of participation and interest. The WG should be 
> > concluded, unless there are participation and interest by 
> > September 1st or October 1st at the latest.
> > 
> > Regards,
> > Kam Lam 
> > 
>

---

From: "Marek Malowidzki" <[email-masked]>
Date: Wed, 11 Aug 2004 10:19:58 +0200

> Hi AToMMIBer,
>
> If you are interested in the IMA MIB as a new work item or
revising/advancing the existing MIBs, please show your interest and have
action soon. Otherwise the WG will be concluded as noted by the AD.
> In the case of advancing the existing MIBs, more implementation feedbacks
are needed.

Ok, so I am showing our interest in this WG, although I am not sure if this
will be sufficient for the group to exist.

I have been reading this group for las few years (and I believe there are
more such people). We are implementing an SNMP agent for an ATM switch. The
MIB we are interested are mostly ATM-MIB, ATM2-MIB, ATMFCES-MIB and - in the
next step - in the IMA MIB. Currently, we are working on CES and would be
glad to provide our opinions on this topic.

Our low activity on this group stems probably from the fact that we asked
questions here in the past but did not receive help. (Of course, I realize
that most members are probably volunteers - nonetheless, our questions were
closely related to ATM standard MIBs). For example, one important issue we
had to solve (that I recall now) is the right way to establish
one-directional ATM connections (PVCs). We think that the standard is
unclear in how exactly this issue should be solved. Surprisingly, we could
not find help anywhere - we were analyzing obsolete ATM-MIB versions,
comments that we could find through Google, we sent e-mails to MIB authors,
etc. Finally, taking everything into account, we think we understand how
this should be solved. One additional statement in the RFC could answer all
questions.

Another significant problem is the lack of standard ATM MIB for QoS and
resource management. Every vendor's MIB, which we have read, takes a
different and incompatible approach. I believe, unfortunately, that it is
too late now to propose such a MIB for the standardization process.

We would be glad to discuss various issues related to CES MIBs, if this is
the right forum. For example, due to complex relationships between various
MIB tables, we are trying to collect all available information in a "CES
algorithm", a set of rules, which would explain on a step-by-step basis what
and where should be changed when a given table row changes. Without such a
document, I think that any implementation does not make sense due to
complexity. Or, is anyone aware of a similar document available anywhere?

Marek Malowidzki