Re: Rmon2-mib advancement

At 08:50 AM 1/20/2005, David B Harrington wrote:
>Hi,
>
>I see from the IETF61 minutes that the AD-Review requested changes to
>the text of TimeFilter:
>
>"1.2) Advancement of RFC 2021 (RMON-2) to DS
>
>The current draft of the RMON-2 MIB (F) has been updated
>to address the AD Review comments.  The current state is 'AD
>Followup'.
>There were no comments on the draft except for the TimeFilter TC.  
>There is text in this TC that needs correction and clarification.  
>The most significant changes are:
>  - correct: mangled text related to agent response
>  - clarify: timestamp applies to entire row, not a timestamp per 
>    column or counter
>  - remove text: deleted rows cannot be detected with TimeFilter
>
>Replacement text will be sent to the WG mailing list.  After
>any corrections, the MIB will be updated.  No new WG Last Call
>will be held for this minor clarification."
>
>Will the replacement text be published to the WG mailing list soon? 

yes

>The minutes do not spell out just what fixes were requested by the AD.
>Will it fix the get-next-forever TimeFilter problem discussed in
>archive message #672, that has not yet been resolved?
>(The proposed solution was abandoned, but the I don't see that the WG
>chose to not fix the problem.)

The TimeFilter get-next-forever was declared a non-issue
awhile back. Consider this the official notification.
The WG decided that the agent is allowed to advance the
TimeFilter to suppress duplicate entries, and we don't
need any MIB objects to identify the mode because the
manager can easily tell which mode the agent uses, and
the mode may not be the same in every table (e.g.,
multi-sub-agent implementation).

> 
>It would be good to be able to provide corrected TimeFilter text to
>implementors, like the implementor that sent the message below.

What does the VLAN index==0 have to do with TimeFilter?


>dbh

Andy



>> -----Original Message-----
>> From: IEEE 802.1 [mailto:[email protected]] On Behalf 
>> Of Eelco Chaudron
>> Sent: Thursday, January 20, 2005 2:35 AM
>> To: [email protected]
>> Subject: [802.1] [802.1AB]: Problem with the 
>> lldpXdot1RemProtoVlanEntry table inde x
>> 
>> Hi All,
>> 
>> When implementing the dot1 extension MIB I was running into a 
>> problem with
>> the lldpXdot1RemProtoVlanTable.
>> The table has the following indexes:
>>   - lldpRemTimeMark
>>   - lldpRemLocalPortNum
>>   - lldpRemIndex
>>   - lldpXdot1RemProtoVlanId
>> 
>> The problem lies within the last index, 
>> lldpXdot1RemProtoVlanId. This can
>> have a value of zero, and would be causing an infinite loop 
>> when doing SNMP
>> getnext operations.
>> 
>> To my understanding a SNMP index can never have a value of zero, as
>it
>> indicates to SNMP to get the first value.
>> 
>> How would we hande this? For example not returning entries in the
>> lldpXdot1RemProtoVlanTable wich have a vlanid of zero? Or 
>> report the zero
>> values as 4096?
>> 
>> Regards,
>> 
>> Eelco
>> 
>> IEEE 802.1 list info: 
>> http://www.ieee802.org/1/email-pages/etkg1204.html
>> 
>
>
>
>_______________________________________________
>RMONMIB mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmonmib