[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