[CCAMP] A comment on draft-galimbe-kunze-g-698-2-snmp-mib

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 28 March 2012 07:57 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C32F21F8819 for <ccamp@ietfa.amsl.com>; Wed, 28 Mar 2012 00:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.555
X-Spam-Level:
X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6+--LudJQxW for <ccamp@ietfa.amsl.com>; Wed, 28 Mar 2012 00:57:34 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id C272321F8818 for <ccamp@ietf.org>; Wed, 28 Mar 2012 00:57:33 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2S7vWNE010246 for <ccamp@ietf.org>; Wed, 28 Mar 2012 08:57:32 +0100
Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2S7vV6n010240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ccamp@ietf.org>; Wed, 28 Mar 2012 08:57:31 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'CCAMP' <ccamp@ietf.org>
Date: Wed, 28 Mar 2012 08:57:32 +0100
Message-ID: <091501cd0cb8$6ebe8d70$4c3ba850$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac0MuGsYc0ztIFX0RLOOpOIKhdTeDA==
Content-Language: en-gb
Subject: [CCAMP] A comment on draft-galimbe-kunze-g-698-2-snmp-mib
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2012 07:57:34 -0000

Listening to Malcolm's comment at the mic just now, it makes a lot of sense to
me to make sure that parameters cannot be independently set in an inconsistent
way.

There are two ways to achieve this in a MIB module:

The first way (which seems to be what this I-D is doing - but I have only
skim-read) is to make the max-Access clause of the objects read-only. That means
that the detailed parameters can be read, but are consequence of the setting of
the major parameters of the link.

The other option is to describe (in the Description clauses) the conflicts that
are not allowed and how the SET operations must fail when conflicting values are
set. This seems particularly complex in the case of black links, but is still
achievable.

Just my $0.02

Adrian