[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-eos-oidcompression-00.txt





On Tue, 1 May 2001, Robert Story wrote:

> > Perhaps the wording of
> >the document should indicate that the Command Generator SHOULD
> >(instead of MUST) determine whether or not the Command Responder supports
> >the new PDUs and OID compression before sending a message with the
> >new PDU type and OID compression.
> >
> This is exactly what I wanted. I should have been specific and I would have
> saved us both a bunch of typing.

Okay.  I don't see any problem with changing the wording from MUST to
SHOULD unless someone else has strong feeling against this. 

> I agree that <table>.2.<row> would be useful in table OID compression for
> non-row PDUs.


If scalars are also going to be allowed in the row-operations PDUs then
I think the <table>.2 format will be needed for the row PDUs as well.

> I agree that it would be more efficient, but I still think that it can/will
> result in unexpected behavior. The larger a network grows, the more likely
> someone will have a device with out of date firmware that will confuse an
> unknowing script/operator. And I think the cost, byte-wise, is reasonable
> considering the savings from table OID suppression.

Okay. I think we definitely need to consider this issue further.
It may be that everyone will agree that the extra cost is worth the
ability to more easily handle potential problems like this. Or, perhaps
some people would prefer to have a choice so that the management
application can somehow specify if it wants implicit or explicit column
identification based on the request it makes. Any thoughts?

			-Sandra


****************************************************************************
Sandra McLeod <mcleod@snmp.com>
SNMP Research International         |   voice: +1 865 579-3311
3001 Kimberlin Heights Road         |   fax: +1 865 573-9197
Knoxville, TN  37920                |   WWW:  http://www.snmp.com