Counters for Multicast Blocks and Bytes Sent

[[e-mail]]

Hi,

I have now had several different people ask about Multicast Bytes sent, and
why there is not such counter in the MIB.  I posted some information
previously but the short answer is that it was not in the original phase iv
specification.  I have confirmed this with the current architect.  Given that
there seems to be a desire to have a more thorough accounting of phase iv
multicast traffic, I am reposting a proposed solution by one of the people who
is currently implementing the phiv MIB.

They also have some additions/corrections they would like posted as well.  I
would like to have some response from this list if there are objections or
alternate solutions.  If there are none, then I will add these to the very short
list of edits I am saving up for when we think we are ready to move to draft
(which is probably not soon).

I have assumed that we are not yet ready for interoperability testing, but would
be willing to try to help put something together in the fall if people are
interested.  Please let me know.

/jon




--------------------------------Forwared Note---------------------------------


     Hi Jon,

        Thanks for your mail message. As we discussed over the phone,

     1) The phivCountersCountEntry has two typos.

	phivCountersCountDataBlksRecd { phivCountersCountEntry 8 } is the same
	as phivCountersCountDataBlocksRecd { phivCountersCountEntry 4 }.

	Similarly, phivCountersCountDataBlksSent { phivCountersCountEntry 9 }
	is the same as phivCountersCountDataBlocksSent { phivCountersCountEntry 5 }.

	Because phivCountersCountEntry does not have any entries for

	phivCountersCountMcastBytesSent : Number of multicast bytes sent,

	 and

        phivCountersCountMcastBlksSent : Number of multicast messages sent,

       it would be helpful if we could rename the variables

       phivCountersCountDataBlksRecd to phivCountersCountMcastBytesSent.
	
       and

       phivCountersCountDataBlksSent to phivCountersCountMcastBlksSent.

   2)  Also, since now DECnet-Phiv is also supported over token ring,
       it would be helpful if there is an enumeration for token ring in

	phivCircuitCommonType { phivCircuitParametersEntry 7 }

        and

	phivLineProtocol { phivLineEntry 8 }

   3)   In phivCircuitCountEntry, we have the following counters,

	       phivCircuitCountBytesRecd
	           PhivCounter,
	       phivCircuitCountBytesSent
	           PhivCounter,
	       phivCircuitCountDataBlocksRecd
	           PhivCounter (0..65535),
	       phivCircuitCountDataBlocksSent
	           PhivCounter,

	Because phivCircuitCountBytesRecd is actually the count of data
	bytes received, it would clarify the semantics better, if we could
	rename phivCircuitCountBytesRecd to phivCircuitCountDataBytesRecd

	Similary since phivCircuitCountBytesSent is actually the count of
	data bytes sent, it would clarify the semantics better, if we could
	rename phivCircuitCountBytesSent to phivCircuitCountDataBytesSent.

   4)   Similarly, phivCountersCountEntry has the following counters,

	       phivCountersCountBytesRecd
	           PhivCounter,
	       phivCountersCountBytesSent
	           PhivCounter,
	       phivCountersCountDataBlocksRecd
	           PhivCounter,
	       phivCountersCountDataBlocksSent
	           PhivCounter,

	Because phivCountersCountBytesRecd is actually the count of data
	bytes ( datalink data) received, it would clarify the semantices better,
	if we could rename phivCountersCountBytesRecd to
	phivCountersCountDataBytesRecd.

	Because phivCountersCountBytesSent is actually the count of data
	bytes ( datalink data) received, it would clarify the semantices better,
	if we could rename phivCountersCountBytesSent to
	phivCountersCountDataBytesSent.

     Please acknowledge the receipt of this message.
	
     Jim Hill and Apurva Mehta





------- End of Forwarded Message