Rmon2-mib advancement

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? 

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.)
 
It would be good to be able to provide corrected TimeFilter text to
implementors, like the implementor that sent the message below.

dbh

> -----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
>