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

snmpconf Re: ipsec-cfg MIB



David Waitzman wrote:
> 
> I wrote:
> > > The MIBs have some 4096 octet strings.  Does this conform with the
> > > current BCP for SNMP?   I would have thought a much clumsier split of
> > > the objects into <MMS sized hunks is necessary.
> 
> 
> Ricky Charlet wrote:
> > I'm very glad of your comment that we should focus on conforming to BPC
> > of SNMPCONF as we develop the IPsec Policy MIB. But I have to admit that
> > I can't pace your acronym 'MMS'. Could you explain further please?
> 
> I was using "BCP" as in its generic sense of "Best Current Practice",
> not referring to a particular draft.
> 
> "MMS" means maximum message size, and limits the packet size, so if the
> MMS is assumed to be 1500 or so octets, then a 4096 octet variable can't
> ever fit.  Early SNMPv1 assumed for safety an MMS of 484 bytes (a
> minimum value that all managers/agents needed to work with)!  RFC1351
> may have the first explicit definition of the term in SNMP space.
> 
> He also wrote:
> > The large majority of the octect strings are our "common names" (look
> > at the Textual Convention we defined. These are used as indicies to all
> > the tables. The reasons that we create these octet strings has to do
> > with our managment software and its capabilities rather than any SNMP
> > BPC.
> 
> I understand.
> 
> And he also wrote:
> > That mib is a work for future Redcreek devices.  I'd be glad to answer
> > questions about it but not on this list. This discussion will have to be
> > about the IETF work on a new IPsec Policy MIB.
> 
> That means that you don't (yet) have proof by deployment that the MIB
> works.  That's quite ok and is just a useful data point if people
> reading the MIB think they see problems of the form "how can this
> possibly work"?
> 
> -david


Ah ha, Now I'm getting what you are talking about.  Those 4K byte MIB
objects are intended to hold certificates which have an undetermined
maximum size. I think that you are proposing that overly large objects
with unclear maximum sizes like these be downloaded to the device as a
series of smaller blocks. I think the idea has merit. And I would be
intersted in what folks in the SNMPCONF space have to say about a BCP
when sending down very large objects to divices. Therefore, I am cross
posting this to snmpconf@snmp.com


-- 
  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903