On 18/04/2014 04:17, Nobo Akiya (nobo) wrote:
Hi Sam,
-----Original Message-----
From: Sam K. Aldrin [mailto:aldrin.ietf@xxxxxxxxx]
Sent: Thursday, April 17, 2014 9:24 PM
To: Nobo Akiya (nobo)
Cc: Jeffrey Haas; ietf@xxxxxxxx; 'Black, David'; adrian@xxxxxxxxxxxx; rtg-
bfd@xxxxxxxx; 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.
-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
.