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 protected]> wrote: > 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. 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). > > > 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. 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 > neighbors, the State Group tables of the NHDP-MIB [RFC6779] module > are aligned with this MIB module. > > > > Best Regards, > Alexey > > > > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
