[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ipcdn] pktcMtaDevProvConfigKey
Hi Randy,
You wrote:
> > pktcMtaDevProvConfigKey OBJECT-TYPE
> ...
> > and, the MTA MUST return a 'genErr' error in response to
> > SNMP GET operations."
> ...
>
> This strikes me as very strange. The intent in RFC 3416 section 4.2.1
> was for genErr to be the "error of last resort". When one considers
> how this would interact with, for example, AgentX
> infrastructure, the consequences for Get-Next and Get-Bulk
> processing could well be very bad.
Eugene and I discussed this live today. We had not thought about that
before, you have a point.
Do I interpret your comment above correctly by assuming that, on some
SNMP agents, the return of a genErr would break a MIB walktrhough via
get-next/get-bulk for e.g.? If that is the case, I agree we don't want
this.
> My suggestion, since this
> object contains sensitive information anyway, is for it to
> always return a zero-length string, rather than playing
> strange games with error codes.
Ok.
I assume a "zero length string" means an octet string of size 0?
How about this new text?
pktcMtaDevProvConfigKey OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0|8))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the key used to encrypt/decrypt
the configuration file when secure SNMPv3 provisioning
is used.
The privacy algorithm is DES, the key length is 64 bits.
If this object is set at any other provisioning steps than
the one(s) allowed by the PacketCable MTA Device
Provisioning Specification, or, if this object is
set to a zero-length string value, the MTA MUST return
an 'inconsistentValue' error.
This object must not be used in non secure provisioning
mode. In non secure provisioning modes, the MTA MUST
return an 'inconsistentValue' in response to SNMP SET
operations, and, the MTA MUST return a zero-length string
in response to SNMP GET operations."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
PacketCable Security Specification."
::= { pktcMtaDevServer 10 }
Let us know if the above is acceptable. Thanks for raising this issue.
> (I also see no value to requiring that the three objects be
> set in the same PDU. It would increase agent complexity, and
> I see no benefits to doing so.)
Removed from all objects where it had been inserted.
Eugene will start a thread on this before the change gets in the
draft.
>
> Randy
_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn