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

[Jeffrey Haas]

On Thu, Apr 17, 2014 at 09:18:28PM +, Nobo Akiya (nobo) wrote:
> > I did not see a compliance requirement for a system that only implements
> > BFD protocol version 0.  That absence should at least be mentioned
> > somewhere.  For example, if this reflects a considered and deliberate
> > decision by the WG, that should be mentioned in the introduction.
> 
> Good point. If I remember correctly, BFD version 0 had a problem in the state 
> machine that can cause the two ends to fall into a deadlock. It would be, 
> therefore, very bad for anybody to have BFD version 0 deployed out there, and 
> asking for any MIB compliance requirement for such. Consensus on absence of 
> compliance requirement for BFD version 0 was never polled in the WG, but I 
> can say that there shouldn't be any desire for that.

With respect to v0 vs. v1 from a MIB perspective, the only user-visible
detail was the additional state in the state machine.  That means that the
MIB in its current form should be able to accommodate bfd v0.

This does suggest, however, that the TC mib could use a comment in the
DESCRIPTION toward the point that failing(5) is only valid for BFD v0.

A conformance clause indicating that those so foolish as to deploy BFD v0
would better be served by the determinism of a five-year-old child flipping
a coin is probably out of scope for the draft.  But if someone has
sufficiently proscriptive text to add to say "don't do bfd v0" that is
acceptable to the reviewers, I'm fine with that.

-- Jeff

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Thomas Nadeau]

On Apr 18, 2014:5:41 AM, at 5:41 AM, Benoit Claise  wrote:

> On 18/04/2014 04:17, Nobo Akiya (nobo) wrote:
>> Hi Sam,
>> 
>>> -Original Message-
>>> From: Sam K. Aldrin [mailto:aldrin.i...@gmail.com]
>>> Sent: Thursday, April 17, 2014 9:24 PM
>>> To: Nobo Akiya (nobo)
>>> Cc: Jeffrey Haas; i...@ietf.org; 'Black, David'; adr...@olddog.co.uk; rtg-
>>> b...@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.

--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
>> .
>> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

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

[Jeffrey Haas]

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.  

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).

-- Jeff

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Benoit Claise]

On 18/04/2014 13:51, Thomas Nadeau wrote:

On Apr 18, 2014:5:41 AM, at 5:41 AM, Benoit Claise  wrote:


On 18/04/2014 04:17, Nobo Akiya (nobo) wrote:

Hi Sam,


-Original Message-
From: Sam K. Aldrin [mailto:aldrin.i...@gmail.com]
Sent: Thursday, April 17, 2014 9:24 PM
To: Nobo Akiya (nobo)
Cc: Jeffrey Haas; i...@ietf.org; 'Black, David'; adr...@olddog.co.uk; rtg-
b...@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

.





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Benoit Claise]

On 18/04/2014 04:17, Nobo Akiya (nobo) wrote:

Hi Sam,


-Original Message-
From: Sam K. Aldrin [mailto:aldrin.i...@gmail.com]
Sent: Thursday, April 17, 2014 9:24 PM
To: Nobo Akiya (nobo)
Cc: Jeffrey Haas; i...@ietf.org; 'Black, David'; adr...@olddog.co.uk; rtg-
b...@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.


-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

.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Benoit Claise]

Hi Adrian,

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:

http://www.ietf.org/iesg/statement/writable-mib-module.html

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.
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.

Thanks for the explanation. That makes sense to me.
This would be a useful addition to the writeup.

Regards, Benoit


Cheers,
Adrian


.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Sam Aldrin]

Hi Randy,

On Apr 17, 2014, at 8:43 PM, Randy Presuhn  wrote:

> Hi -
> 
>> From: "Sam K. Aldrin" 
> ...
>> Sent: Thursday, April 17, 2014 9:53 PM
>> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
> ...
>> 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.
> 
> Then what's the problem?  If the WG has consensus to add functionality, and
> that functionality logically requires a read-write MIB module of extension,
> the IESG policy already allows for such cases.

Yes, that is what I wanted to clarify, when I sent my email, to find if there 
is WG consensus to go with write-access objects, as this base MIB will have 
implication on the other MIB in the pipeline?

We had quite a big thread on MPLS list on this very subject and wanted to avoid 
the repeat.
http://www.ietf.org/mail-archive/web/mpls/current/msg11598.html

cheers
-sam
> 
> Randy
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Randy Presuhn]

Hi -

> From: "Sam K. Aldrin" 
...
> Sent: Thursday, April 17, 2014 9:53 PM
> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
...
> 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.

Then what's the problem?  If the WG has consensus to add functionality, and
that functionality logically requires a read-write MIB module of extension,
the IESG policy already allows for such cases.

Randy

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Sam K. Aldrin]

Hi Randy,

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

> Hi -
> 
>> From: "Sam K. Aldrin" 
>> 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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Randy Presuhn]

Hi -

>From: "Sam K. Aldrin" 
>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.

Randy

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Sam Aldrin]

Thanks, Nobo. Much appreciated.

-sam
On Apr 17, 2014, at 7:17 PM, Nobo Akiya (nobo)  wrote:

> Hi Sam,
> 
>> -Original Message-
>> From: Sam K. Aldrin [mailto:aldrin.i...@gmail.com]
>> Sent: Thursday, April 17, 2014 9:24 PM
>> To: Nobo Akiya (nobo)
>> Cc: Jeffrey Haas; i...@ietf.org; 'Black, David'; adr...@olddog.co.uk; rtg-
>> b...@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.
> 
> -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
>>> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Nobo Akiya (nobo)]

Hi Sam,

> -Original Message-
> From: Sam K. Aldrin [mailto:aldrin.i...@gmail.com]
> Sent: Thursday, April 17, 2014 9:24 PM
> To: Nobo Akiya (nobo)
> Cc: Jeffrey Haas; i...@ietf.org; 'Black, David'; adr...@olddog.co.uk; rtg-
> b...@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.

-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
> >

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Nobo Akiya (nobo)]

Hi Jeff,

> -Original Message-
> From: Jeffrey Haas [mailto:jh...@pfrc.org]
> Sent: Thursday, April 17, 2014 6:15 PM
> To: Nobo Akiya (nobo)
> Cc: Black, David; tnad...@lucidvision.com; Zafar Ali (zali); General Area
> Review Team (gen-art@ietf.org); rtg-...@ietf.org; i...@ietf.org
> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
> 
> On Thu, Apr 17, 2014 at 09:18:28PM +, Nobo Akiya (nobo) wrote:
> > > I did not see a compliance requirement for a system that only
> > > implements BFD protocol version 0.  That absence should at least be
> > > mentioned somewhere.  For example, if this reflects a considered and
> > > deliberate decision by the WG, that should be mentioned in the
> introduction.
> >
> > Good point. If I remember correctly, BFD version 0 had a problem in the
> state machine that can cause the two ends to fall into a deadlock. It would
> be, therefore, very bad for anybody to have BFD version 0 deployed out
> there, and asking for any MIB compliance requirement for such. Consensus
> on absence of compliance requirement for BFD version 0 was never polled
> in the WG, but I can say that there shouldn't be any desire for that.
> 
> With respect to v0 vs. v1 from a MIB perspective, the only user-visible detail
> was the additional state in the state machine.  That means that the MIB in its
> current form should be able to accommodate bfd v0.
> 
> This does suggest, however, that the TC mib could use a comment in the
> DESCRIPTION toward the point that failing(5) is only valid for BFD v0.

Agree, and it's already there :)

[snip]
IANAbfdSessStateTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"BFD session state. State failing(5) is only applicable if
 corresponding session is running in BFD version 0."
[snip]

-Nobo

> 
> A conformance clause indicating that those so foolish as to deploy BFD v0
> would better be served by the determinism of a five-year-old child flipping
> a coin is probably out of scope for the draft.  But if someone has 
> sufficiently
> proscriptive text to add to say "don't do bfd v0" that is acceptable to the
> reviewers, I'm fine with that.
> 
> -- Jeff

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Sam K. Aldrin]

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.

-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
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Nobo Akiya (nobo)]

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Sam K. Aldrin]

Hi Jeff,

Comments inline.

On Apr 17, 2014, at 3:18 PM, Jeffrey Haas wrote:

> 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. 

-sam

> 
> -- Jeff

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Sam K. Aldrin]

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:
>> 
>>  http://www.ietf.org/iesg/statement/writable-mib-module.html
>> 
>> 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: 
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? 

cheers
-sam
> 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
> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Nobo Akiya (nobo)]

Hi David,

Thank you for thorough review of this document.
Please see replies in-line.

> -Original Message-
> From: Black, David [mailto:david.bl...@emc.com]
> Sent: Wednesday, April 16, 2014 7:31 PM
> To: tnad...@lucidvision.com; Zafar Ali (zali); Nobo Akiya (nobo); General
> Area Review Team (gen-art@ietf.org)
> Cc: rtg-...@ietf.org; i...@ietf.org; Black, David
> Subject: Gen-ART review of draft-ietf-bfd-mib-17
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> 
> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-bfd-mib-17
> Reviewer: David L. Black
> Review Date: April 16, 2014
> IETF LC End Date: April 28, 2014
> 
> Summary: This draft is on the right track, but has open issues
>   described in the review.
> 
> This draft is a MIB module for the BFD protocol, which is an important low-
> level routing protocol.  The draft is reasonable for a MIB draft; one needs to
> go read the protocol documents to understand how the protocol works, and
> significant portions of the text are derived from the usual MIB "boilerplate"
> as one would expect.  The "Brief Description of MIB Objects" is indeed brief,
> but reasonable.  The shepherd writeup indicates that there are multiple
> implementations.
> 
> Major issues:
> 
> This MIB contains many writable objects, so the authors should take note of
> the IESG statement on writable MIB modules:
> 
>   http://www.ietf.org/iesg/statement/writable-mib-module.html
> 
> 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).

I remember seeing the statement from IESG, which I agree is a good direction 
for new charter items. [This] BFD MIB, on the other hand, is almost 10 years 
old, with several implementations already around. I highly suspect the WG will 
not want to see *change of direction* at this point. With that said, let me 
take this up with the AD and the Shepherd.

> 
> Minor issues:
> 
> The security considerations section includes considerations for
> unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus,
> but omits the corresponding considerations for bfdAdminStatus and
> bfdSessNotificationsEnable.  Both of the latter objects are global, so
> significant damage can be inflicted via these objects with a small number of
> unauthorized modifications, so they need to be included in the first list of
> sensitive objects.

Good point. I will add bfdAdminStatus and bfdOperStatus in the security 
considerations section.

> 
> I suggest that the authors recheck the entire MIB to ensure that every object
> or table that should be included in the security considerations section is
> appropriately included.

I've gone through them. There are set of objects which really should not be 
modified once a session is functioning. I've added this in the security 
considerations section.

   o  Some management objects define the BFD session whilst other
  management objects define the parameter of the BFD session.  It is
  particularly important to control the support for SET access to
  those management objects that define the BFD session, as changes
  to them can be disruptive.  Implementation SHOULD NOT allow
  changes to following management objects when bfdSessState is
  up(4):

  *  bfdSessVersionNumber
  *  bfdSessType
  *  bfdSessDestinationUdpPort
  *  bfdSessMultipointFlag
  *  bfdSessInterface
  *  bfdSessSrcAddrType
  *  bfdSessSrcAddr
  *  bfdSessDstAddrType
  *  bfdSessDstAddr

> 
> Also, as a General Variable, would bfdSessNotificationsEnable be better
> named bfdNotificationsEnable, as it's not in the BFD Session Table?

That's true. Renamed as suggested.

> 
> I did not see a compliance requirement for a system that only implements
> BFD protocol version 0.  That absence should at least be mentioned
> somewhere.  For example, if this reflects a considered and deliberate
> decision by the WG, that should be mentioned in the introduction.

Good point. If I remember correctly, BFD version 0 had a problem in the state 
machine that can cause the two ends to fall into a deadlock. It would be, 
therefore, very bad for anybody to have BFD version 0 deployed out there, and 
asking for any MIB compliance requirement for such. Consensus on absence of 
compliance requirement for BFD version 0 was never polled in the WG, but I can 
say that there shouldn't be any desire for that.

I will add a short statement on lack of BFD version 0 compliance requirement in 
the introduction section, as you suggested.

> 
> Nits/editorial comments:
> 
> In the security considerations for authentication-related objects:
> 
> OLD
>In order for these sensitive informati

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

[Black, David]

Hi Adrian,

As clarified in my response to Nobo, I raised the concern about writable
MIB modules primarily as a process check (I was expecting to find something
on this topic in the shepherd writeup, and didn't).  In particular, this
concern was not intended as a strong reason not to publish, and I have no
disagreements with any of the points in your message below.

With you on top of this and the OPS folks sure to notice, I have no doubt
that this will get suitably addressed, although it might be simpler to
ensure that the OPS Area is ok now rather than waiting for IESG Evaluation.

Thanks,
--David (in part, wearing his OPS Directorate member "hat").

> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Thursday, April 17, 2014 5:55 PM
> To: Black, David; tnad...@lucidvision.com; z...@cisco.com; n...@cisco.com;
> 'General Area Review Team'
> Cc: rtg-...@ietf.org; i...@ietf.org
> Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17
> 
> 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:
> >
> > http://www.ietf.org/iesg/statement/writable-mib-module.html
> >
> > 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.
> 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
> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Adrian Farrel]

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:
> 
>   http://www.ietf.org/iesg/statement/writable-mib-module.html
> 
> 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.
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


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Black, David]

Hi Nobo,

> > This MIB contains many writable objects, so the authors should take note of
> > the IESG statement on writable MIB modules:
> >
> > http://www.ietf.org/iesg/statement/writable-mib-module.html
> >
> > 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).
> 
> I remember seeing the statement from IESG, which I agree is a good direction
> for new charter items. [This] BFD MIB, on the other hand, is almost 10 years
> old, with several implementations already around. I highly suspect the WG will
> not want to see *change of direction* at this point. With that said, let me
> take this up with the AD and the Shepherd.

I have no problem with "running code" as a good reason to continue with
writable objects in this MIB; taking this topic up with your AD and Shepherd
should suffice.

> > I suggest that the authors recheck the entire MIB to ensure that every 
> > object
> > or table that should be included in the security considerations section is
> > appropriately included.
> 
> I've gone through them. There are set of objects which really should not be
> modified once a session is functioning. I've added this in the security
> considerations section.

Good - thank you for doing that.

Everything else is fine with me, and I appreciate the prompt response.

Thanks,
--David

> -Original Message-
> From: Nobo Akiya (nobo) [mailto:n...@cisco.com]
> Sent: Thursday, April 17, 2014 5:18 PM
> To: Black, David; tnad...@lucidvision.com; Zafar Ali (zali); General Area
> Review Team (gen-art@ietf.org)
> Cc: rtg-...@ietf.org; i...@ietf.org
> Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17
> 
> Hi David,
> 
> Thank you for thorough review of this document.
> Please see replies in-line.
> 
> > -Original Message-
> > From: Black, David [mailto:david.bl...@emc.com]
> > Sent: Wednesday, April 16, 2014 7:31 PM
> > To: tnad...@lucidvision.com; Zafar Ali (zali); Nobo Akiya (nobo); General
> > Area Review Team (gen-art@ietf.org)
> > Cc: rtg-...@ietf.org; i...@ietf.org; Black, David
> > Subject: Gen-ART review of draft-ietf-bfd-mib-17
> >
> > I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> > ART, please see the FAQ at
> >
> > .
> >
> > Please resolve these comments along with any other Last Call comments
> > you may receive.
> >
> > Document: draft-ietf-bfd-mib-17
> > Reviewer: David L. Black
> > Review Date: April 16, 2014
> > IETF LC End Date: April 28, 2014
> >
> > Summary: This draft is on the right track, but has open issues
> > described in the review.
> >
> > This draft is a MIB module for the BFD protocol, which is an important low-
> > level routing protocol.  The draft is reasonable for a MIB draft; one needs
> to
> > go read the protocol documents to understand how the protocol works, and
> > significant portions of the text are derived from the usual MIB
> "boilerplate"
> > as one would expect.  The "Brief Description of MIB Objects" is indeed
> brief,
> > but reasonable.  The shepherd writeup indicates that there are multiple
> > implementations.
> >
> > Major issues:
> >
> > This MIB contains many writable objects, so the authors should take note of
> > the IESG statement on writable MIB modules:
> >
> > http://www.ietf.org/iesg/statement/writable-mib-module.html
> >
> > 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).
> 
> I remember seeing the statement from IESG, which I agree is a good direction
> for new charter items. [This] BFD MIB, on the other hand, is almost 10 years
> old, with several implementations already around. I highly suspect the WG will
> not want to see *change of direction* at this point. With that said, let me
> take this up with the AD and the Shepherd.
> 
> >
> > Minor issues:
> >
> > The security considerations section includes considerations for
> > unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus,
> > but omits the corresponding considerations for bfdAdminStatus and
> > bfdSessNotificationsEnable.  Both of the latter objects are global, so
> > significant damage can be inflicted via these objects with a small number of
> > unauthorized modifications, so they need to be included in the first list of
> > sensitive objects.
> 
> Good point. I will add bfdAdminStatus and bfdOperStatus in the security
> considerations section.
> 
> >
> > I suggest that the authors recheck the entire MIB to ensure that every
> object
> > or table that should be included in the security considerations section is
> > appropriately included.
> 
> I've gone through them. There are set of objects which really should not be
> modified once a session is functioning. I've added this in the

[Gen-art] Gen-ART review of draft-ietf-bfd-mib-17

[Black, David]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-bfd-mib-17
Reviewer: David L. Black
Review Date: April 16, 2014
IETF LC End Date: April 28, 2014

Summary: This draft is on the right track, but has open issues
described in the review.

This draft is a MIB module for the BFD protocol, which is an important low-
level routing protocol.  The draft is reasonable for a MIB draft; one needs
to go read the protocol documents to understand how the protocol works, and
significant portions of the text are derived from the usual MIB "boilerplate"
as one would expect.  The "Brief Description of MIB Objects" is indeed
brief, but reasonable.  The shepherd writeup indicates that there are
multiple implementations.

Major issues:

This MIB contains many writable objects, so the authors should
take note of the IESG statement on writable MIB modules:

http://www.ietf.org/iesg/statement/writable-mib-module.html

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).

Minor issues:

The security considerations section includes considerations for
unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus,
but omits the corresponding considerations for bfdAdminStatus and
bfdSessNotificationsEnable.  Both of the latter objects are global,
so significant damage can be inflicted via these objects with a
small number of unauthorized modifications, so they need to be
included in the first list of sensitive objects.

I suggest that the authors recheck the entire MIB to ensure that
every object or table that should be included in the security
considerations section is appropriately included.

Also, as a General Variable, would bfdSessNotificationsEnable be better
named bfdNotificationsEnable, as it's not in the BFD Session Table?

I did not see a compliance requirement for a system that only
implements BFD protocol version 0.  That absence should at least be
mentioned somewhere.  For example, if this reflects a considered and
deliberate decision by the WG, that should be mentioned in the
introduction.

Nits/editorial comments:

In the security considerations for authentication-related objects:

OLD
   In order for these sensitive information
   from being improperly accessed, implementers MAY wish to disallow
   access to these objects.
NEW
   In order to prevent this sensitive information
   from being improperly accessed, implementers MAY disallow
   access to these objects.

idnits 2.13.01 found a truly minor nit that should be corrected when
the draft is next revised:

  == Outdated reference: A later version (-05) exists of
 draft-ietf-bfd-tc-mib-04

it also generated a warning that probably does not reflect an actual problem:

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
 have content which was first submitted before 10 November 2008.  If you
 have contacted all the original authors and they are all willing to grant
 the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
 this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
 (See the Legal Provisions document at
 http://trustee.ietf.org/license-info for more information.)

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com    Mobile: +1 (978) 394-7754


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art