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.

(Stewart Bryant) Yes

(Adrian Farrel) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-07-10 for -03)
No email
send info
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)

(Spencer Dawkins) No Objection

Comment (2013-07-10 for -03)
No email
send info
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) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2013-07-11 for -03)
No email
send info
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.

(Pete Resnick) No Objection

Comment (2013-07-11 for -03)
No email
send info
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.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection