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

Benoit Claise <bclaise@cisco.com> Fri, 18 April 2014 12:06 UTC

Return-Path: <bclaise@cisco.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 C05931A01F6; Fri, 18 Apr 2014 05:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.773
X-Spam-Level:
X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 bZXkzubpP6WY; Fri, 18 Apr 2014 05:06:50 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6B91A0208; Fri, 18 Apr 2014 05:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5179; q=dns/txt; s=iport; t=1397822806; x=1399032406; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WMcgKt5iEVVOziy2T0Qu/vnY+NvLYvE0yk6xHct/scg=; b=DvcK+m+JKy2TbUZducgPC4glzQRmHCKUUID1pFs0yI7Vth6DUiRgvQaV D1YhdSRFveJARXZP7R5nd/sRxIOE3R9Dlxydz2qsozi7sGMPdBwyvVFZC grN2V16vzmQHTTDgjCDLRxWj9/YKIQCZ9qd31wU+eF1S7/GLtnjM3fTCv 0=;
X-IronPort-AV: E=Sophos;i="4.97,884,1389744000"; d="scan'208";a="14946174"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 18 Apr 2014 12:06:45 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3IC6i88025687; Fri, 18 Apr 2014 12:06:44 GMT
Message-ID: <53511554.2000402@cisco.com>
Date: Fri, 18 Apr 2014 14:06:44 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Thomas Nadeau <tnadeau@lucidvision.com>
Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> <20140417221850.GD29430@pfrc> <8BA1120C-3C89-4F73-A937-D7C118704553@gmail.com> <CECE764681BE964CBE1DFF78F3CDD3941E10BDAE@xmb-aln-x01.cisco.com> <7B5FD180-D744-415B-AA0E-12EB11AF7245@gmail.com> <CECE764681BE964CBE1DFF78F3CDD3941E10BE1F@xmb-aln-x01.cisco.com> <5350F335.8020309@cisco.com> <33B44E73-320B-4FC9-8438-E471F605F318@lucidvision.com>
In-Reply-To: <33B44E73-320B-4FC9-8438-E471F605F318@lucidvision.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/VYXKdgDMd6Gxd6Vj8kQf7wtS5SQ
Cc: "ietf@ietf.org" <ietf@ietf.org>, "Black, David" <david.black@emc.com>, Farrel Adrian <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 12:06:55 -0000

On 18/04/2014 13:51, Thomas Nadeau wrote:
> On Apr 18, 2014:5:41 AM, at 5:41 AM, Benoit Claise <bclaise@cisco.com> wrote:
>
>> On 18/04/2014 04:17, Nobo Akiya (nobo) wrote:
>>> Hi Sam,
>>>
>>>> -----Original Message-----
>>>> From: Sam K. Aldrin [mailto:aldrin.ietf@gmail.com]
>>>> Sent: Thursday, April 17, 2014 9:24 PM
>>>> To: Nobo Akiya (nobo)
>>>> Cc: Jeffrey Haas; ietf@ietf.org; 'Black, David'; adrian@olddog.co.uk; rtg-
>>>> bfd@ietf.org; Zafar Ali (zali); 'General Area Review Team'
>>>> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
>>>>
>>>> Hi Nobo,
>>>> [sorry for the top post]
>>>>
>>>> Yes, this is an old MIB and was in existence for a long time.
>>>> 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 that is the painful part, where community at large has not
>>>> shown interest in developing write-access MIB's at IETF, lest
>>>> implementation.
>>>>
>>>> I want to re-iterate again, I am not objecting or proposing an alternative
>>>> option. Just wanted to get clarification, so that, we don't have to burn cycles
>>>> and do the exercise again, when we have to review these new extension
>>>> MIB's.
>>> That's a good point, it would be good to have this clarified for future work.
>>>
>>> IMO:
>>>
>>> For new charters, IESG encourages NETCONF/YANG. This means S-BFD (if gets included in the charter) should look into NETCONF/YANG (i.e. not extension to the BFD base MIB).
>>>
>>> For currently chartered BFD tasks, the BFD WG should continue with writable MIB. Large part of that is the BFD base & MPLS MIBs which [painful] writable effort is mostly done already.
>> This is in essence what https://www.ietf.org/iesg/statement/writable-mib-module.html says.
>>
>> Regards, Benoit.
> 	Yes, this is why we left the writable stuff in - and why I recently spent about 4 hours doing Adrian's edits around support of such things.  Lets please put the discussion around read-write to bed for these two modules as they clearly were well under way and complete by the time the statement came out.
No disagreement.

Regards, B.
>
> 	--Tom
>
>
>
>>> -Nobo
>>>
>>>> -sam
>>>>
>>>> On Apr 17, 2014, at 6:04 PM, Nobo Akiya (nobo) wrote:
>>>>
>>>>> Hi Sam,
>>>>>
>>>>>>> On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote:
>>>>>>>> %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:
>>>>>> http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ 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?
>>>>>>> As noted in earlier mailing list chatter, there is some support for
>>>>>>> write access in existing implementations.  Given the lack of
>>>>>>> significant detail when pressed for the name of such an
>>>>>>> implementation, I'm suspecting smaller vendor or internal
>>>>>>> implementation.  That's still sufficient to leave write available.
>>>>>>>
>>>>>>> Given that one of the original contexts of asking if we could remove
>>>>>>> write was whether IETF was being asked to provide such a thing for
>>>>>>> MPLS-TP with related impact on your extension MIB and the answer was
>>>>>>> "no", that shouldn't be the main criteria.
>>>>>> No. The context of my question is not related to MPLS-TP as such, but
>>>>>> write- access support in general.
>>>>>> I should have added 'clarification' in my earlier email.
>>>>>>> My suspicion is that if we were to ship the base MIB with writeable
>>>>>>> objects, we may be forced to consider similar things for the
>>>>>>> extension
>>>>>> MIB(s).
>>>>>> Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE
>>>>>> and BFD-MIB respectively,  with write-access. Had to do write-access
>>>>>> because of the reason you've mentioned above, which is base MIB. It
>>>>>> would be painful to publish/support write-access MIB's when there is
>>>>>> no clear interest. Hence my clarification question.
>>>>> This mentions three vendors wanting to implement MIB as writable.
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01382.html
>>>>>
>>>>> And one more vendor voicing for writable.
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01397.html
>>>>>
>>>>> I agree that defining & wording writable MIB is much more painful than all
>>>> read-only MIB. But above thread indicates the desire by multiple vendors to
>>>> implement writable BFD MIB. Therefore it does seem that there are
>>>> interests, and going forward with write-access will benefit the community.
>>>> And with *ReadOnlyCompliance defined, BFD MIB can also accommodate
>>>> those implementing them as just read-only.
>>>>> -Nobo
>>>>>
>>>>>> -sam
>>>>>>
>>>>>>> -- Jeff
>>> .
>>>
>>