Early Review of draft-ietf-babel-information-model-03
I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
Reviewer: Acee Lindem
Review Date: September 24th, 2018
IETF LC End Date: Not started yet.
Intended Status: Informational
I don’t believe the document should be continued. Given the lack of precision in the definitions, I’d recommend abandoning the work and going directly to the YANG model. I also have some major concerns.
The summary says it all.
1. The abstraction of babel-security-obj is too abstract to be useful. Furthermore, babel-security-trust alludes to certificates signed by CAs. However, if you are using these for routing, it is not clear how the PKI is accessed. It would be infinitely more useful to define what is used for the extant security mechanism (e.g., HMAC).
2. While the descriptive text says that some objects MUST be configured, there is no precise specification of which are configurable and which are not.
3. The contents and structure of babel-hello-ucast-history and babel-hello-mcast-history is incomprehensible. Why aren’t these objects represented as lists with the format of the list elements defined?
4. The “Security Considerations” section discussion is woefully inadequate – it basically says that configuration must be secured. This is another reason to go to the YANG model where all this is defined.
1. The format for the object descriptions is hard to consume. It would be preferable to use complete sentences and mixed rather than a continuous stream of lowercase separate by semi-colons.
2. Why isn’t there an IPv4 multicast address in babel-constant-obj?
3. It is unclear how babel-txcost and babel-rxcost are derived. This should either be specified or there should be an appropriate reference to the section in the base specification.
4. It is unclear how ECMP routes are supported in babel-routes-obj.
5. If is implementation-specific how babel-route-calculated-metric is calculated, shouldn’t there be some indication of the algorithm used? It seems all Babel routers in the domain should be using a similar algorithm.
1. Inconsistent uppercase and lowercase reference to “Babel”. See diff.
2. Use US English spelling of “neighbor” consistently.
ACEE-M-G2HR:Desktop acee$ diff draft-ietf-babel-information-model-03.txt.orig draft-ietf-babel-information-model-03.txt
< implementation (via a management protocol such as netconf) to report
> implementation (via a management protocol such as NETCONF) to report
< that can be used to created management protocol data models (such as
< a netconf [RFC6241] YANG data model).
> that can be used to create management protocol data models (such as
> a NETCONF [RFC6241] YANG data model).
< model is focused on reporting status of the Babel protocol, and very
< little of that is considered mandatory to implement (conditional on a
> model is focused on reporting Babel protocol operational state, and very
> little of that is considered mandatory to implement (contingent on a
< parameters may be configurable; however, it is up to the Babel
> parameters may be configurable. However, it is up to the Babel
< the minimal number of values, and n is the maximum. The symbol * for
< n means no upper bound.
> the minimun number of list elements and n indicates the maximum number
> of list elements. The symbol * for n means there no defined limit on
> the number of list elements.
< o enable/disable babel
> o enable/disable Babel
< o Interface: enable/disable babel on this interface
> o Interface: enable/disable Babel on this interface
> } babel-information-obj;
< babel-enable: if true, the babel implementation is running; if
< false, the babel implementation is not currently running; MAY be
< configurable to allow babel to be started or stopped
> babel-enable: if true, the Babel implementation is running; if
> false, the Babel implementation is not currently running; MAY be
> configurable to allow Babel to be started or stopped
> } babel-constants-obj;
> } babel-interfaces-obj;
< babel-interface-enable: if true, babel sends and receives messages
< on this interface; if false, babel messages received on this
> babel-interface-enable: if true, Babel sends and receives messages
> on this interface; if false, Babel messages received on this
< babel-message-log-enable: if true, logging of babel messages
< received on this interface is enabled; if false, babel messages
> babel-message-log-enable: if true, logging of Babel messages
> received on this interface is enabled; if false, Babel messages
< link layer; the rxcost is sent to a neighbour in each IHU
> link layer; the rxcost is sent to a neighbor in each IHU
< the neighbour table: the statistics kept in the neighbour table
> the neighbor table: the statistics kept in the neighbor table
> } babel-security-obj;
> } babel-routes-obj;
> } babel-credential-obj;
> } babel-log-obj;
< expose babel route filtering rules by adding a route filtering object
> expose Babel route filtering rules by adding a route filtering object