Subject: Atommib WG meeting summary

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 4 Aug 2004 23:43:38 -0400

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: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 5 Aug 2004 19:28:20 +0200

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 -
> 
> The atommib working group met for one session on Tuesday 
> afternoon at the San Diego IETF-60th meeting.  
> 
> 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: "Faye Ly" <[email-masked]>
Date: Wed, 11 Aug 2004 17:53:44 -0700

Marek,

I am sorry you have not been getting answers on your questions.  Most
likely it is because no one is familiar with the one directional ATM PVC
like myself.  

ATM QoS is defined in the ATM MIB?  Do you mean you need additional QoS
support?  As for CAC or resource management, you are right, it doesn't
exist.  It should be a simple extention to the existing ATM MIB though.

For ATM Forum CES MIB, this is interesting but not in this group's
charter.  If we can't get IMA MIB going in this group the chance of
getting support for CES MIB is slim.  But other people may want to speak
up ...

-faye

-----Original Message-----
From: Marek Malowidzki [mailto:[email-masked]] 
Sent: Wednesday, August 11, 2004 1:20 AM
To: [email-masked]
Subject: Re: Atommib WG meeting summary

> 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