Re: [manet] ETT metrics draft

[Ulrich Herberg <[e-mail]>]

Henning,

thanks for your reply. See below:

On Mon, Jul 22, 2013 at 2:14 AM, Henning Rogge
<[e-mail]> wrote:
> On 07/16/2013 11:29 PM, Ulrich Herberg wrote:
>>
>> Hi,
>>
>> I have also reviewed the draft. Since it's an early draft, just some
>> high-level comments:
>>    - I like the idea of specifying the ETT metrics and I hope you will
>> issue a new revision.
>
>
> We definitely will. Expect a new revision in the week after the IETF
> meeting.

Good!


>
>
>>    - The introduction is a bit confusing. It talks about the Funkfeuer
>> networks, and then suddenly jumps into details about ETT metric. I
>> would suggest to focus the document on the metric itself, and
>> mentioning the Funkfeuer networks only in the appendix.
>
>
> Maybe a "history" appendix that explains where the ETX part of the metric
> comes from?

Yes, that would be a good idea IMO.


>> I also wonder
>>
>> why the intended status is informational? Shouldn't it be Experimental
>> or Standards Track, since a protocol extension is specified?
>
>
> Good question, I am not sure about this but I am open for advise.

Let's discuss that during the IETF.



>>    - section 3 (Applicability); again, I would defocus on the Funkfeuer
>> networks, just mention in general the use cases where the metric is
>> useful. You should focus more on OLSRv2 itself, IMO.
>>    - same section: "ETX metric that was used in the earlier [RFC3626]
>> implementation". Note that RFC3626 only uses hop-count, so technically
>> the olsr.org implementation was not RFC3626 compliant
>
>
> Yes.
>
>
>>    - section 7: Since the link tuples are extended, does that mean that
>> draft-ietf-manet-olsrv2 is "updated" (in the IETF sense)? If so, the
>> draft does not say that in the header, nor mention that in the
>> introduction and abstract.
>
>
> I wrote the link tuple extension as a way to have "link specific" data
> stored for the metric. Do you think it would be better to put this into a
> database described in this draft?

After a second thought, I actually think it's fine not to "update" the
OLSRv2 spec, since this is an optional extension, and so the
information sets in OLSRv2 remain unchanged for implementations not
using the ETT extension.



>> I assume that an informational document
>>
>> could also not do that.
>>   - "L_ETT_last_pkt_seqno  is the last received packet sequence number
>> received from this link." Shouldn't there some section somewhere to
>> describe requirements, such as access to lower layers (e.g., packet
>> sequence numbers)?
>
>
> I don't consider packet sequence numbers as a different layer. Its a
> different interface to the rfc5444 (de)multiplexer, but its still in the
> same layer.
>
> We use IP addresses from the IP header in NHDP/OLSRv2 without worrying about
> "lower layer access" too.

I agree that there is some ambiguity. I think such a (short)
requirements section could be helpful for implementers to make sure
that they can get appropriate information from other layers. But if
you think this is self-evident, I am fine if you leave it as is.



>>   - section 9 mixes a bit the different layers (RFC5444 and RFC6130). I
>> wonder if that could not be more separated.
>
>
> Hmm.
>
>
>>   - some lower case "must" in section 9; should that be 2119 or not?
>
>
> Will have to look at this.
>
>
>>   - section 13: Shouldn't that be a new link metric type allocation?
>> How is the metric used in the OLSRv2 network?
>
>
> Not sure if we want to allocate metric TLV extensions for specific metric
> types.

I thought that this is the purpose of the registry. Let's discuss that
during the IETF.



>>   - why is OLSRv2 only an informative reference? Can there be normative
>> references in an Informational document?
>
>
> I thought only RFCs can be a normative reference, but my knowledge about rfc
> types and references types in them is a bit limited.

Yes, but OLSRv2 needs to be a normative reference for the ETT draft.
In case this draft is completed before OLSRv2 becomes an RFC (which I
hope not!), then it will be hold in the RFC editor queue until OLSRv2
gets the RFC number.
Here is some info about the reference types:
http://www.ietf.org/iesg/statement/normative-informative.html

Best regards
Ulrich