Subject: [Gen-art] Gen-ART Review of draft-ietf-manet-olsrv2-mib-07

From: Alexey Melnikov <[email-masked]>
Date: Fri, 03 May 2013 14:39:15 +0100

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> Document: 
draft-ietf-manet-olsrv2-mib-07 Reviewer:  Alexey Melnikov Review Date: 
03 May 2013 IETF LC End Date: 23 April 2013 IETF Telechat Date: 16 May 
2013 Summary: This draft is ready for publication as Proposed Standard 
(with nits)
- Major Issues: None - Minor Issues:

In multiple places:

           This object is persistent and when written
           the entity SHOULD save the change to
           non-volatile storage."

Why is this a SHOULD? I.e., is there a good reason not to save
such values (other than crashing while doing that, which I think is
not something you can prevent anyway.) It really looks like MUST
is actually appropriate here.

     olsrv2FHoldTime  OBJECT-TYPE
        SYNTAX      Unsigned32
        UNITS       "milliseconds"
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
           "olsrv2FHoldTime corresponds to
            F_HOLD_TIME of OLSRv2 and represents the period
            after receipt of a message that is forwarded by this
            router for which that information is recorded, in order
            that the message is not forwarded again if received again.

            Guidance for setting this object may be found
            in Section 5 of the OLSRv2 specification (RFC XXXX),
            which indicates that:
               o olsrv2FHoldTime > 0
               o This parameter should be greater
                 than the maximum difference in time that a
                 message may take to traverse the MANET,
                 taking into account any message forwarding
                 jitter as well as propagation, queuing,
                 and processing delays.

            This parameter SHOULD be greater
            than the maximum difference in time that a
            message may take to traverse the MANET,
            taking into account any message forwarding
            jitter as well as propagation, queuing,
            and processing delays.

I think the last paragraph is effectively identical from the one before it.
You don't do this for other attributes. I think the last paragraph should
be deleted.

- Nits: 6.2.  Relationship to the NHDP-MIB    OLSRv2 depends on the 
neighborhood information that is discovered by    [RFC6130].  In order 
access In order *to* access ?    the Objects relating to discovered    
neighbors, the State Group tables of the NHDP-MIB [RFC6779] module    
are aligned with this MIB module. Best Regards, Alexey

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 3 May 2013 11:29:05 -0700

Alexey,

thank you very much for your review. Please see my reply below:

On Fri, May 3, 2013 at 6:39 AM, Alexey Melnikov
<[email-masked]> wrote:
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>
> Document: draft-ietf-manet-olsrv2-mib-07
> Reviewer:  Alexey Melnikov
> Review Date: 03 May 2013
> IETF LC End Date: 23 April 2013
> IETF Telechat Date: 16 May 2013
>
> Summary: This draft is ready for publication as Proposed Standard (with
> nits)
>
>
> - Major Issues: None
>
> - Minor Issues:
>
> In multiple places:
>

This is in accordance with the NHDP-MIB Module (RFC6779). The
rationale is that MANET routers may be very constrained in terms of
memory, much more than classical Internet routers. So while it makes a
lot of sense to recommend storing the information persistently, it may
just not be feasible (running out of memory) or undesirable (too
little memory / no memory).

> You don't do this for other attributes. I think the last paragraph should

Good catch. I agree with you and will delete the last paragraph.

> - Nits:
>
>
> 6.2.  Relationship to the NHDP-MIB
>
>    OLSRv2 depends on the neighborhood information that is discovered by
>    [RFC6130].  In order access
>
> In order *to* access ?

Thanks, I will correct that.

Best regards
Ulrich

>
>    the Objects relating to discovered
>    are aligned with this MIB module.
>
>
>
> Best Regards,
> Alexey
>
>
>
>
>
>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 07 May 2013 20:55:00 +0100

> little memory / no memory).
I think providing some examples for why this is a SHOULD (as you 
explained above) would be valuable.

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 8 May 2013 13:29:10 -0700

Alexey,

On Tue, May 7, 2013 at 12:55 PM, Alexey Melnikov
<[email-masked]> wrote:
[...]

> I think providing some examples for why this is a SHOULD (as you explained
> above) would be valuable.

I agree and will add a sentence similar to what I described in my email.

Best regards
Ulrich

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 May 2013 21:13:04 +0300

Alexey,

Thank you very much for your review. These reviews are important for me, as I base my IESG approval recommendations mostly on them. Ulrich, based on this review and my own quick review, I have balloted No-Objection.

Jari