Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
draft-ietf-manet-olsrv2-rmpr-optimization-01

[Ballot comment]
Section 3, first paragraph:

  include it.  However inclusion of this optimization is advised, it
  can, in some cases, create smaller and fewer messages, without ever
  having the opposite effect.

This is nitpicky, but I wish you'd use some conjunction other than a comma between "advised" and "it" on the first line, or else make it two sentences.

[Ballot comment]
Since other ADs have already raised the issues I spotted with this document, I will simply point out that the MPR acronym needs to be expanded and should not appear in the Abstract.

[Ballot comment]
- I read multiple times these sentences, and I'm not sure what they mean:

  Note that an implementation using this optimization is not strictly
  compliant with the current specification [OLSRv2], ...

  This specification updates [OLSRv2] to specify that an implementation
  using this optimization is compliant with the protocol OLSRv2.


- I agree with Barry's DISCUSS

- I Would appreciate if you would expand MPRs (multipoint relays) earlier in the draft.

[Ballot discuss]
I'm raising Pete's comment to a DISCUSS: the conflict between the MAY and RECOMMENDED in Section 4 isn't just an editorial thing... it really is conflicting normative language that has to be resolved.  I know that the authors are dealing with this, so there's no need to respond here.  I'll clear when Pete's comment is resolved.

[Ballot comment]
I'm impressed: a Standards Track document that goes into IESG Evaluation with a -00 version.

I look forward to the day when there's an extension to optimize this optimization of the Optimized Link State Routing Protocol.  Just sayin'.

[Ballot comment]
These two statements seem in conflict:

  A set of routing MPRs created as specified in [OLSRv2] MAY be
  optimized in the following manner.

[...]

  It is RECOMMENDED that all OLSRv2 routers use this optimization.

The first indicates that the optimization is purely an option. The second indicates that it is a requirement with certain exceptions that may exist. Which do you mean? If the former, I'd suggest just getting rid of both of the 2119 terms (use "can" instead of "MAY" and "suggested" instead of "RECOMMENDED"), since it's only a suggestion. If the latter, change the "MAY" to a "SHOULD".

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-manet-olsrv2-rmpr-optimization-00, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Routing MPR Optimization for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Routing MPR Optimization for the Optimized Link State Routing Protocol
  version 2 (OLSRv2)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-02-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification updates the Optimized Link State Routing Protocol
  version 2 (OLSRv2) with an optimization to improve the selection of
  routing MPRs.  The optimization retains full interoperability between
  implementations of OLSRv2 with and without this optimization.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-rmpr-optimization/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-rmpr-optimization/ballot/


No IPR declarations have been submitted directly on this I-D.

AD review
========

Hi Authors,

I have done my usual AD review of this document and found only a few
trivial editorial issues (well, it is a short document, and the
authors are reported to be competent).

I will start the IETF last call and raise these issues to be addressed
as part of the last call.

Thanks for the work.

Adrian

===

The Shepherd write-up notes idnits that need to be fixed, but I see
none.

---

I think MPR could usefully be expanded in the document title, in the
Abstract, and on first use in the body.  Then you won't need to expand
it in Section 3.

---

It seems odd that Section 4 has a bullet numbered "1." but no other
numbered bullets.

---

I think Section 4 uses the notation of 18.2 of [OLSRv2] not 18.3. At
least, that is where d1() etc. are defined for revision -19 of that
document.

---

(1) The request is to publish this document as a Standards Track RFC,
and this is indicated in the document header.

The Optimized Link State Routing Protocol version 2 (OLSRv2) has been published as Standards Track. This extension updates the OLSRv2 RFC by defining an optimization to improve the selection of routing MPRs.  The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization.

(2) Document Announcement Write-Up.

Technical Summary

The abstract of this document is included below.

This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing MPRs.  The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization.


Working Group Summary

There was consensus to publish the document.


Document Quality

There is one publicly known implementation this extension to OLSRv2:

o Ecole Polytechnique, France
  (Contact: Thomas Clausen)



Personnel

The Document Shepherd is Ulrich Herberg (ulrich@herberg.name); the
responsible Area Directors are Adrian Farrel and Stewart Bryant.

(3) The document Shepherd has participated in review both in the Working
Group, and has run the "idnits" tool against the draft.

(4) The Document Shepherd has no concerns about the reviews of the
document; they have been thorough.

(5) The authors do not believe that additional reviews are required,
aside from the usual directorate reviews during IETF last call.

(6) The Document Shepherd has no concerns with the document.

(7) All authors have confirmed that they are unaware of any IPR needing
disclosure; there are no known IPR claims related to this document.

(8) No IPR disclosures have been filed, as none are required.

(9) WG consensus appears to be strong.

(10) Nobody has threatened an appeal or otherwise indicated extreme discontent.

(11) Some ID nits were found, and should be addressed by the authors in the next revision. This can be done along with addressing other potential comments during IETF LC.

(12) Mib Doctor, media type, and URI reviews are not required.

(13) All references have been defined as either normative or
informative.

(14) No normative references exist to documents not ready for
advancement. Of the normative references, OLSRv2 is not yet an RFC, but has been approved for publication and is in the RFC editor queue.

(15) There are no normative downward references.

(16) Publication of this document will update OLSRv2 (no RFC number assigned yet). The RFC-to-be is listed on the title page header, listed in the abstract, and discussed in the introduction.

(17) There is no IANA consideration in the document.

(18) There is no IANA consideration in the document.

(19) The Document Shepherd has run the idnits tool against the document; the remaining warning will be resolved in a new revision to be submitted by the authors after the IETF LC.