Re: pktcMtaDevProvConfigKey

Hi -

> From: "Jean-Francois Mule" <[email protected]>
> To: <[email protected]>
> Sent: Monday, January 24, 2005 10:47 PM
> Subject: RE: [ipcdn] pktcMtaDevProvConfigKey
...
> > The point is that
> >     (1) subagent protocols provide no way for a subagent to know
> >           which encryption algorithm was used for a given request
> >     (2) SNMP engines may support multiple encryption algorithms
> >     (3) if PacketCable ever permits the use of the more secure AES,
> >          specifying things in terms of "the same 'encryption
> > algorithm; as the
> >          one [sic] chosen for SNMPv3 privacy" is just plain broken.
>
> Your comment here is on the PacketCable and Ipcablecom 1.0 security
> specifications to which the MTA MIB module is just providing managed objects.
> I would not argue that some improvements could be made in the spec itself -
> but that's what we have today and we can't fix this by MIB changes. This is
> not specific to IPCDN: we define often mibs after protocols and when we
> find issues, we log them for the next revision. I think we can record your
> comment and pass it on to the proper folks for consideration when they
> update the security spec.
> Ok?

Ok.

...
> > >level of SNMP security. Perhaps we should change 'non secure
> > >provisioning modes' to 'Basic and Hybrid Flows' (Since they are the
> > >technical terms used in PacketCable). Would that help?
> >
> > It would help immensely.
> I would actually rather not since we now use "provisioning modes"
> through the mib module. I would prefer introducing a paragraph or 2
> upfront specifying what the provisioning modes are and what they
> refer to in terms of provisioning flows.
> Is that ok?
...

That would be fine with me.  Making it clear that the "provisioning flows"
are not the ones carried by SNMP would also help, since at least some
of us are actually accustomed to using SNMP to provision things.

Randy