-----Original Message-----
From: Nobo Akiya (nobo) [mailto:nobo(_at_)cisco(_dot_)com]
Sent: Thursday, April 17, 2014 5:18 PM
To: Black, David; tnadeau(_at_)lucidvision(_dot_)com; Zafar Ali (zali);
General Area
Review Team (gen-art(_at_)ietf(_dot_)org)
Cc: rtg-bfd(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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(_dot_)black(_at_)emc(_dot_)com]
Sent: Wednesday, April 16, 2014 7:31 PM
To: tnadeau(_at_)lucidvision(_dot_)com; Zafar Ali (zali); Nobo Akiya
(nobo); General
Area Review Team (gen-art(_at_)ietf(_dot_)org)
Cc: rtg-bfd(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
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 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.
Thanks for the text. Updated in local copy.
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
Agree, non-issue.
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.)
Agree, non-issue.
Thanks again!
-Nobo
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(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------