Re: [babel] I-D Action: draft-ietf-babel-information-model-08.txt

["STARK, BARBARA H" <[e-mail]>]

> # Section 1.
> 
> "one of these security mechanisms" -> "one or both of these security
> mechanisms"

Done
 
> "(contingent on a management protocol with Babel support being
> implemented)"
> I don't know what this means

If your Babel implementation has a data model and you want to claim compliance with the info model, then you must have these parameters.
I didn't want this concept confused with the idea that if you do a Babel implementation you have to implement a data model that is compliant with the info model. That would be wrong.
And I didn't want it confused with the idea that the parameters must have values (cannot be NULL).
Mahesh and I have had a lot of discussion over what MTI in this draft means, so I was trying to explain it better. But I agree I still didn't get it right.
I suggest changing this parenthetic to "(for an implementation attempting to comply with this information model)"

> "a referential [...] structure."  I don't know what this means

For example, SQL uses a purely referential structure for its data (each table is stand-alone, and they are linked through means of foreign keys), rather than hierarchical. It would be possible to create a SQL data model from this (mostly) hierarchical info model.
Should something change here?
 
> # Section 3.2
> 
> "Default is ff02:0:0:0:0:0:1:6".  Why not write this as ff02::1:6, as is usual?

I think I just copied it from somewhere (like the IANA IPv6 multicast address registry). But I'm fine with the shorter version.
Done.

> # Section 3.3
> 
> The metric computation algorithm is described twice, here and globally in the
> babel-information-obj.  Is the global value a default for newly created
> interfaces, or does it provide a value in case the interface-obj doesn't specify
> it?  Please clarify.

The global parameter is a read-only list of algorithms supported by the implementation. It's used to constrain the value in interfaces. The initial value used for an interface will always be set by an implementation, using whatever logic is internal to the implementation. But whatever value the implementation uses needs to be in the global list of supported algorithms. It's also allowed for the implementation to let a user change the value set by the implementation -- in which case the user needs to know the allowed set of values it can be changed to (and constrained to setting it to a supported algorithm).

> The same goes for babel-hmac-algorithm.

Similar answer. But since the parameter is moving from interfaces to mac-keys (so it can be specific to a key), it won't be set by the implementation. It's set by the user when adding the key. But it still needs to be constrained to an algorithm the implementation supports (as indicated by the list in the global parameter).
[Also: changing the babel-mac-algorithm, per decision to make hmac draft a mac draft.]

> # Section 3.4
> 
> Aren't we missing an entry for the total number of packets sent?

So in addition to totals of multicast hellos and updates separately, include a total of all Babel packets sent on the interface? I could add that, if people think it would be useful. I'm going to hold off on adding this to see if anyone else has an opinion. I think if this were done, it doesn't make sense to require the more granular "sent" counts (if statistics are implemented). They would become optional. But I think seeing counts for hellos and updates separately is more useful for seeing how the implementation is behaving. And if you have those counts, the combined count provides no additional value. So I'm sort of conflicted.

> Should these entries be optional?

Having the babel-if-stats-obj is optional (under interfaces). But if the implementation has the babel-if-stats-obj, then I think all 3 of these statistics should be required. 
 
> # Section 3.5
> 
> I don't think that the nbr-stats entries is useful.  A neighbour is a transient
> data structure, and neighbours get destroyed when they become
> unreachable.  Thus, there is no good place to persist the statistics.
> I suggest moving all statistics into the interface-obj, and not keeping per-
> neighbour stats.

I'm fine with that. That would suggest putting optional babel-sent-ucast-hello, babel-sent-ucast-update, and babel-sent-IHU under the interfaces statistics (where all 3 are totals sent to all neighbors on the interface). The 3 received statistics parameters go away (babel-received-hello, babel-received-update, babel-received-IHU). Do others have opinions? If no-one says otherwise, I'll do this.
 
> babel-exp-{m,u}cast-hello-seqno: the use of 0 for undefined is not a good
> idea, since 0 is a perfectly valid seqno.

OK. Then this goes in the same bucket as the other read-only int parameters that need to have a NULL distinct from zero. Is the following ok?

      Expected {m,u}cast Hello sequence
      number of next Hello to be received from this neighbor. 
      If {m,u}cast Hello packets are not expected, or processing of
      {m,u}cast packets is not enabled, this MUST be NULL. This is a 16-bit unsigned
      integer; if the data model uses zero (0) to represent NULL values
      for unsigned integers, the data model may use a different data
      type that allows differentiation between zero (0) and NULL.

> babel-ucast-hello-seqno: what's the value when the implementation is not
> sending unicast hellos?

Same sort of thing?

      The current sequence number in use for
      unicast Hellos sent to this neighbor.  If unicast Hellos are not being sent,
      this MUST be NULL.  This is a 16-bit unsigned
      integer; if the data model uses zero (0) to represent NULL values
      for unsigned integers, the data model may use a different data
      type that allows differentiation between zero (0) and NULL.

> babel-cost: this is written in a different style.  I suggest something like "the
> link cost, as computed from...".

OK
 
> # Section 3.6
> 
> See above.  I suggest moving this into the interface-stats object, and only
> keeping aggregate statistics.

As above discussed above, then.
 
> # Section 3.7
> 
> babel-route-router-id: suggst "the router-id of the router that originated this
> route".

OK
 
> # Section 3.9
> 
> babel-key-use-{sign, verify}: good idea, I'll add this to the implementation.

Thank you. I took the idea from the babel-hmac spec. And Toke refined it.

> babel-hmac-test: why non-empty?

If there's no mac algorithm that will choke on zero-length input string, then I guess empty is ok. I'm thinking I won't have issues with NULL/zero/empty ambiguity, since it's a binary string.
So just change that sentence to "Input to this operation is a binary string." (instead of "Input to this operation MUST be a non-empty binary string.")? Same for the babel-cert-test? Unless I hear otherwise, I'll do the same change to both.

Barbara