[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ppt slides for draft-ietf-eos-snmp-bulkdata-01.txt
[ post by non-subscriber ]
Hi Bryan and David,
I would like to ask you to revise your SNMP Bulk Data
Transfer Extensions MIB to include support IETF standard
AgentX implementations of it. This would mean adding
at least a statement to that effect in Sec. 2.3, "Design
Goals" and (most importantly) changing the three scalar
objects -- acFileEncoding, acFileCompression, and
acXferProtocol -- into table objects in some way.
Discussing this latter requirement -- there can be no
scalars in a MIB for optimal AgentX implementation -- is
complicated at this point by some other possible problems
with these object definitions, e.g.:
- Should these really be single-valued INTEGERs or
bit-masks that represent the range of capabilities
in each area offered by the [sub-]agent? The
appearance of other objects (xferProtocol,
snapshotFileEncoding, and snapshotFileCompression)
in several tables suggest the a given [sub-]agent
is not limited to just one possibility for
acXferProtocol, acFileEncoding, or acFileCompression...?
If and when you elect to move those three "ac<xxx>"
objects into tabular form, you can do so by putting them
into a table of their own -- perhaps called something
like "acProfilesTable" -- indexed via an object called
something like "acProfileName" that would be an
implementation-specific identifier of snmpAdminString
But I'm just tossing those ideas into the ring...not
really trying to micro-design your MIB...the bottom
line is that you need to provide a facility for multiple
AgentX sub-agents to implement this MIB and you need to
move the current scalars into tabular form in some way
to do this.
I have cc'd the AgentX list on this to invite anyone
on that list who is not on the EOS list to engage in
this discussion...but perhaps we should keep all
follow-up on just the EOS list.
- - - - -
>At 3/17/2002:05:31 PM, firstname.lastname@example.org wrote:
>can be found on my home server:
>this is what I'm planning to present tomorrow (monday) AM.