Re: [babel] info-model: preparing -09 on github

Hi Barabar,

I have one comment on the draft.

Section 3.3 babel-interface-obj has a parameter babel-mac-algorithm, but there is no corresponding explanation for it below. Possibly this might suffice:

babel-mac-algorithm:   The name of the MAC algorithm used on this interface. The value is one of the identities listed as part of babel-mac-algorithms at a global level.

Cheers.

> On Aug 14, 2019, at 8:40 AM, STARK, BARBARA H <bs7652@att.com> wrote:
> 
> I've got a preview of the upcoming -09 version on my github.
> https://github.com/bhstark2/babel-information-model
> 
> The README there has links to the current editor's copy at
> https://bhstark2.github.io/babel-information-model/draft-ietf-babel-information-model.html
> 
> and for a diff between this and -08 at
> http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/id/draft-ietf-babel-information-model-08.txt&url2=https://bhstark2.github.io/babel-information-model/draft-ietf-babel-information-model.txt
> 
> It should have everything that I agreed to do so far, including the nits I mentioned in request for last call, changes from the 2 initial emails Juliusz sent (what I agreed to change was in my response), and changing hmac to mac in all but a couple of places (the doc reference right now is still to babel-hmac, and "HMAC-SHA256" wasn't changed). I deleted all the issue and change log stuff at the end.
> 
> Things I haven't changed but where changes may still happen based on discussion...
> 1. link properties / metric-comp-algorithm / interface-metric-algorithm / split-horizon: I'm leaning away from any new objects for link property grouping. It may still be useful to provide additional info to help people understand the allowed values.*
> 2. babel-mac-key-value description to constrain it according to the babel-mac-key-algorithm allowed key length
> Barbara
> 
> * Proposal was
>  babel-metric-comp-algorithms:  List of supported cost computation
>      algorithms.  Possible values include "2-out-of-3", and "ETX".
>      "2-out-of-3" (a specific case of K-out-of-j ) link sensing is suitable for wired links that are either
>       up, in which case they only occasionally drop a packet, or down, in
>       which case they drop all packets. "ETX" is a link-quality estimation algorithm that is
>       designed to work well with the IEEE 802.11 MAC.
> 
>   babel-interface-split-horizon:  Indicates whether or not the split
>      horizon optimization is used when calculating metrics on this
>      interface.  A value of true indicates split horizon optimization
>      is used. Split horizon optimization is useful when running over a
>      transitive, symmetric link technology, e.g., a
>      point-to-point link or a wired LAN technology such as Ethernet. 
>      It is not appropriate for links not known to be symmetric and transitive; in particular,
>      split horizon is not appropriate for decentralized wireless link
>      technologies (e.g., IEEE 802.11 in ad hoc mode) when routing updates
>      are sent over multicast.
> ---------------------------------------------
> Alternate proposal (since above text was copied straight from rfc6126bis)
>  babel-metric-comp-algorithms:  List of supported cost computation
>      algorithms.  Possible values include "2-out-of-3", and "ETX".
>      "2-out-of-3" is a specific case of K-out-of-j described in [rfc6126bis] A.2.1.
>      "ETX" is described in [rfc6126bis] A.2.2.
> 
>   babel-interface-split-horizon:  Indicates whether or not the split
>      horizon optimization is used when calculating metrics on this
>      interface.  A value of true indicates split horizon optimization
>      is used. Split horizon optimization is described in [rfc6126bis] 3.7.4.
> 
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
mjethanandani@gmail.com