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

"Sam K. Aldrin" <> Thu, 17 April 2014 22:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 45E821A0100; Thu, 17 Apr 2014 15:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u9_pYKbvpYtm; Thu, 17 Apr 2014 15:11:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::234]) by (Postfix) with ESMTP id D3D081A00FE; Thu, 17 Apr 2014 15:11:21 -0700 (PDT)
Received: by with SMTP id rr13so817177pbb.25 for <multiple recipients>; Thu, 17 Apr 2014 15:11:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LFXLyYpahXiiwnMu44Nc1E4R1kYqRN49rDIcE/QeGfo=; b=hEaJUEsbwsaPkVvXJvmykvB/SjKfpBJPXbck3oieXVwQndHu9UX3k/h3KV7TjJLNw0 yC9HyPHV/BlJ1J32NbDXcd8P4Mlv/essuIDn30UsHqGNa7Hi69ApxJECNkGfFX2QTowQ p3DTjEbzG2xlrzryaJ04J4lYqgBF5viHgYpztCIf9r0B+QooxMum2JuJjqN7Pu9SIjgR QAbRvEtB7+d9fnkVPlNIYPFT1EVh8sbmwjhb9mpl0vOaioZ2o/dj5KJWEO/l5g1vFRiR CZOuUBR3c0QtSh0oau/iwFrAisF6vbG96ABDHYfWdno2+bJSo3V3Kn7LlGyUGwevVIHn 9GLg==
X-Received: by with SMTP id ah7mr18009827pbd.159.1397772678265; Thu, 17 Apr 2014 15:11:18 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id pl10sm55697899pbb.56.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 15:11:17 -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" <>
In-Reply-To: <051b01cf5a87$b92a84d0$2b7f8e70$>
Date: Thu, 17 Apr 2014 15:11:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <051b01cf5a87$b92a84d0$2b7f8e70$>
X-Mailer: Apple Mail (2.1283)
Cc:, "'Black, David'" <>,,, 'General Area Review Team' <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Apr 2014 22:11:33 -0000

Hi Adrian,

One comment inline.

On Apr 17, 2014, at 2:55 PM, Adrian Farrel wrote:

> Hi David,
> Thanks for the review.
> To pick out one of your points:
>> This MIB contains many writable objects, so the authors should
>> take note of the IESG statement on writable MIB modules:
>> I did not see this mentioned in the shepherd writeup.  If the OPS Area
>> has not been consulted, I strongly suggest doing so during IETF Last
>> Call, e.g., starting with Benoit Claise (AD).
> The OPS Directorate and the MIB Doctors will have been alerted to this document
> by the last call and we can expect their comments.
> But this question was discussed between the AD and the authors, and the AD was
> unlikely to agree to sponsor the document if he felt it went against the IESG
> statement. Our discussion resulted in some reduction of writeable objects.
> I think there are several points to consider:
> 1. This document had already been completed and publication requested (i.e.
> shepherd write-up written) at the time of the IESG statement. It would be
> unreasonable to make the statement retrospective.
> 2. There are already various implementations in equipment (not just management
> stations) of proprietary modules approximating to this document and these
> support write-access.

%sam - If this MIB allows write access, do you/WG anticipate, any extension to the MIB should also provide write-access as well? For example: augments this base MIB to support MPLS. It adds more confusion than solving the issue as base MIB supports write-access, but augmented/ MIB extension doesn't. 

As the BFD MIB authors were not supportive of write-access objects in the MIBs, why to have them in the first place? 

> 3. This is a low-level component protocol of the sort that is used on dumber
> devices and that is an area where write-access is more common.
> Cheers,
> Adrian