[ipcdn] pktcMtaDevProvConfigKey
"Jean-Francois Mule" <jf.mule@cablelabs.com> Fri, 21 January 2005 22:16 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28334 for <ipcdn-archive@ietf.org>; Fri, 21 Jan 2005 17:16:21 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7Kn-0003rX-H7 for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 17:32:53 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs6rW-0004wI-PD; Fri, 21 Jan 2005 17:02:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs6lQ-0002cd-SR for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 16:56:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26932 for <ipcdn@ietf.org>; Fri, 21 Jan 2005 16:56:18 -0500 (EST)
Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs71M-0003F2-HA for ipcdn@ietf.org; Fri, 21 Jan 2005 17:12:50 -0500
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0LLtj1e024392; Fri, 21 Jan 2005 14:55:45 -0700 (MST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: [ipcdn] pktcMtaDevProvConfigKey
Date: Fri, 21 Jan 2005 14:55:45 -0700
Message-ID: <CD6CE349CFD30D40BF5E13B3E0D84804064565@srvxchg.cablelabs.com>
Thread-Topic: [ipcdn] pktcMtaDevProvConfigKey
Thread-Index: AcT/fCha2gOcHp+XSa+y5wmD2GAHbgAfxuoA
From: Jean-Francois Mule <jf.mule@cablelabs.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>, ipcdn@ietf.org
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: quoted-printable
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: quoted-printable
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@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- [ipcdn] pktcMtaDevProvConfigKey Jean-Francois Mule
- Re: [ipcdn] pktcMtaDevProvConfigKey Randy Presuhn
- RE: [ipcdn] pktcMtaDevProvConfigKey Jean-Francois Mule
- Re: [ipcdn] pktcMtaDevProvConfigKey Randy Presuhn
- RE: [ipcdn] pktcMtaDevProvConfigKey Jean-Francois Mule
- Re: [ipcdn] pktcMtaDevProvConfigKey Randy Presuhn
- RE: [ipcdn] pktcMtaDevProvConfigKey Sumanth Channabasappa
- Re: [ipcdn] pktcMtaDevProvConfigKey Randy Presuhn
- RE: [ipcdn] pktcMtaDevProvConfigKey Jean-Francois Mule
- Re: [ipcdn] pktcMtaDevProvConfigKey Randy Presuhn