IETF Logo Mail Archive

Re: Gen-ART review of draft-ietf-bfd-mib-17

"Sam K. Aldrin" <aldrin.ietf@gmail.com> Fri, 18 April 2014 03:53 UTC

Return-Path: <aldrin.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60861A0147; Thu, 17 Apr 2014 20:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp9kF1SqukfW; Thu, 17 Apr 2014 20:53:30 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 339291A00C0; Thu, 17 Apr 2014 20:53:30 -0700 (PDT)
Received: by mail-pa0-f52.google.com with SMTP id rd3so1066974pab.39 for <multiple recipients>; Thu, 17 Apr 2014 20:53:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IPL7jibdZfBm/MKJUWytg45glowdrHwo43dKe8MCkCw=; b=KdIt143+7azLk0RP+nlVOLdWO0Pm2VVRrmwI2EFJuF551H5RcHLnGJybuhjv5wpiHJ tR7/xzCNU11kCd+KPrCZtyxevuYRuRJ4OGVp2qHSijjeinouqXuzqvFcPCz48h8Yecwm MHBHe6BsbDCaMb3oWBm7KAV6OtHIYz2YBbKc+ucEChFBZ1KWEsFv0EbqwO+zu9f2nb6R MSeP33Xfidoj+6Ij9aLUztdYlnx6I+LVr/5KOVj0t1AHmqsChFn+4iZ94xEBPtkYs6j1 eNCa3qkzQkpeWnmkA7JUkU3Jd0rJKRe5Ux9Pr+mBZ4W2opLGvRpwfidx4bDppnBEIkNA GJ0g==
X-Received: by 10.68.178.66 with SMTP id cw2mr19692869pbc.89.1397793206554; Thu, 17 Apr 2014 20:53:26 -0700 (PDT)
Received: from [192.168.1.7] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id ha2sm56880842pbb.8.2014.04.17.20.53.24 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 20:53:25 -0700 (PDT)
Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: "Sam K. Aldrin" <aldrin.ietf@gmail.com>
In-Reply-To: <25276146.1397789275400.JavaMail.root@elwamui-little.atl.sa.earthlink.net>
Date: Thu, 17 Apr 2014 20:53:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B03C974-91FE-48CC-AF82-A82517E106C0@gmail.com>
References: <25276146.1397789275400.JavaMail.root@elwamui-little.atl.sa.earthlink.net>
To: Randy Presuhn <randy_presuhn@mindspring.com>
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/BEBY8m1EiZOuHYkI3FGjTfCvIds
Cc: "ietf@ietf.org" <ietf@ietf.org>, "'Black, David'" <david.black@emc.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>, 'General Area Review Team' <gen-art@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Apr 2014 03:53:31 -0000

Hi Randy,

Inline for my comments.
On Apr 17, 2014, at 7:47 PM, Randy Presuhn wrote:

> Hi -
> 
>> From: "Sam K. Aldrin" <aldrin.ietf@gmail.com>
>> Sent: Apr 17, 2014 6:24 PM
> ...
>> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
> ...
>> My only concern is with the new extension MIB's.
>> If the base MIB (this MIB) has write access,
>> future extension MIB's may be forced to support
>> write-access.
> 
> And how, exactly, does the fact that a base MIB module
> permits write access force extension MIB modules to
> require (or even permit) write access?
> 
> It's perfectly reasonable SMI to define an AUGMENTS
> table consisting entirely of read-only objects.

True, you could add only read-only objects. 
But the point is, not with syntax or what could be added or augmented.
In order to support new functionality, we are extending/augmenting existing base MIB and in addition some write-access objects as well. If we make those new ones read-only objects, then only some objects or tables could be used with write-access and these new objects (read-only) have to be configured differently. In other words, full functionality cannot be provided. This got nothing to do with SMI.

The point we are extending or re-using the base MIB is not to re-define new objects altogether and also to re-use the applications. Atleast that is what we have done in this case.

Hope this clarifies.

cheers
-sam
> 
> Randy

v2.23.0 | Report a Bug | By Email