Use of OSPF-MDR in Single-Hop Broadcast Networks
draft-ietf-ospf-manet-single-hop-mdr-04

Note: This ballot was opened for revision 03 and is now closed.

(Adrian Farrel; former steering group member) Yes

(Stewart Bryant; former steering group member) Yes

(Barry Leiba; former steering group member) No Objection

(Benoît Claise; former steering group member) No Objection

Similarly to the Security Considerations ...

    5. Security Considerations
       This document describes the use of OSPF-MDR in a single-hop broadcast
       network, and raises no security issues in addition to those already
       covered in [RFC5614].

I was hoping for  ...

    6. Management Considerations
       This document describes the use of OSPF-MDR in a single-hop broadcast
       network, and raises no management issues in addition to those already
       covered in [RFC5614]. It actually simplifies the management and operations
       compared to RFC5614 because going from two-hop to a single-hop implies that ...

But wait, there are no management considerations in RFC 5614, and I don't see any related management documents at https://datatracker.ietf.org/wg/ospf/
Granted, it's not fair to have a DISCUSS on this document, and it's too late for RFC5614, but we're left without management considerations.
I'm stuck with a single option for now: let this document go through, but please think about management considerations in the future, either in the document itself, or in a management dedicated document specific to your technology.
In this specific case, let me hope that draft-nguyen-manet-management will address the OSPF-MDR (1 hop and 2 hops)

(Brian Haberman; former steering group member) No Objection

(Gonzalo Camarillo; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Joel Jaeggli; former steering group member) No Objection

(Martin Stiemerling; former steering group member) No Objection

(Pete Resnick; former steering group member) No Objection

I do not know enough about the technology to even know how the following might cause confusion to implementers, but I am utterly mystified by this sentence in section 2:

   o  AdjConnectivity SHOULD be equal to 2 (biconnected), MAY be equal
      to 1 (uniconnected), and SHOULD NOT be equal to 0 (full topology).

Read as 2119 terms: "AdjConnectivity must be set to 2 to avoid damage or interop problems, but there are special cases (unspecified here) where you might not do that. However, 1 is also a perfectly good value. That said, 0 must never be used, in order to avoid damage or interop problems, but there are special cases (unspecified here) where you might use 0, so long as you understand the implications." That sentence seems triply internally self-contradictory.

(Richard Barnes; former steering group member) No Objection

(Sean Turner; former steering group member) No Objection

(Spencer Dawkins; former steering group member) No Objection

In 2.  Operation in a Single-Hop Broadcast Network

   When OSPF-MDR is used in a single-hop broadcast network, the
   following parameter settings and options (defined in [RFC5614])
   should be used:

   o  AdjConnectivity SHOULD be equal to 2 (biconnected), MAY be equal
      to 1 (uniconnected), and SHOULD NOT be equal to 0 (full topology).

Is there any guidance you can give about when the choice of 1 (uniconnected) would be appropriate?

I might also be curious about when the choice of 0 (full topology) would be appropriate, but let's start with 1 (uniconnected).

(Stephen Farrell; former steering group member) No Objection

(Ted Lemon; former steering group member) No Objection

This is a really minor nit, because I suspect anybody (other than me) reading this document already knows what an LSA is before they start, but the acronym is heavily used and never expanded.