OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type
draft-ietf-ospf-hybrid-bcast-and-p2mp-06

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

(Stewart Bryant) Yes

(Ron Bonica) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2012-08-20 for -04)
No email
send info
(Modified after e-mail exchange with Acee Lindem)
Expand "DR" and "BDR" on first reference.

I cleared my Discuss, deferring to and supporting Barry's
Discuss regarding text that explicitly explains how this
document updates the OSPF specification.

(Wesley Eddy) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2012-11-05)
No email
send info
Thank you for addressing my Discuss

(Stephen Farrell) No Objection

Comment (2012-08-13 for -04)
No email
send info
- Its a bit of a concern that the IPR declaration isn't
visible on the tools page [1] for this, but is on the tools
page for draft-nsheth [2] that preceeded this.  Can somoene
do whatever's needed to ensure the IPR declaration will be
linked from the tools page for the eventual RFC? 

   [1] http://tools.ietf.org/html/draft-ietf-ospf-hybrid-bcast-and-p2mp
   [2] http://tools.ietf.org/html/draft-nsheth-ospf-hybrid-bcast-and-p2mp 

- section 3: having read this, the motiviation still isn't
very clear to this reader, perhaps a concrete example of
different costs of communication that this spec addresses
would help.

- 4.1 & 4.2: what does " It MAY be set to "enabled" via
configuration" in 4.1 mean? It seems like a tautology so I
don't know what you're trying to say.  Similarly, in 4.2, "
It MAY be set to a different value using mechanisms which
are outside the scope of this document" is odd.

- expanding DR/BDR in 4.4 would be good.

(Brian Haberman) (was Discuss) No Objection

Comment (2012-08-09 for -03)
No email
send info
Thanks for addressing my DISCUSS points so quickly.

(Russ Housley) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2012-08-21 for -04)
No email
send info
I don't think this should "Update" any other documents, but the IESG has to sort this point out in general, and we shouldn't hold this document up for that.

Total nits, just because I came across them while reviewing; no need to respond to these.

-- Section 1 --
OLD
   to each of the neighboring routers on the network in it's router LSA.
NEW (nit; remove apostrophe)
   to each of the neighboring routers on the network in its router LSA.

OLD
   configuration of the identity of it's neighboring routers.  It also
NEW (nit; remove apostrophe)
   configuration of the identity of its neighboring routers.  It also
Or better...
   configuration of the identity of neighboring routers.  It also

OLD
   network.  Further, it mandates establishment of adjacencies to all
   all configured or discovered neighbors on the network.  However, it
NEW (nit; duplicate "all")
   network.  Further, it mandates establishment of adjacencies to all
   configured or discovered neighbors on the network.  However, it

-- Section 3 --
OLD
   2 topology as well as various link quality metrics such as bandwidth,
   delay and jitter among others.
NEW (nit; add comma)
   2 topology as well as various link quality metrics such as bandwidth,
   delay and jitter, among others.

-- Section 4.2 --
OLD
   Routers MUST support an additional field called the Neighbor Output
   Cost.  This is the cost of sending a data packet to the neighbor,
   expressed in the link state metric.  The default value of this field
   is the Interface output cost.  It MAY be set to a different value
SHOULD THIS BE (adding capitals)?:
   [...] The default value of this field is the Interface Output Cost.

(Pete Resnick) No Objection

Comment (2012-08-13 for -04)
No email
send info
The use of 2119 language in sections 4.1 and 4.2 is bogus. These are all conformance and configuration statements that have nothing to do (at least as stated) with requirements (or options) for interoperability or prevention of damage. For example, in 4.1:

   Routers MUST support configuration of the Router Priority for the
   interface.

   The default value of the LinkLSASuppression is "disabled".  It MAY be
   set to "enabled" via configuration.

Change to:

   Routers implementing this specification will have a configuration option
   for the Router Priority for the interface.

   The default value of the LinkLSASuppression is "disabled".  It may be
   set to "enabled" via configuration.

Similarly for 4.2.

In 4.8, you also have odd constructions with the 2119 language:

   o  If a router is the DR on the interface, it MUST NOT examine the
      pre-restart network LSA for the interface in order to determine
      the previous set of adjacencies.

The requirement is not on the examination, it is on the use. I suggest simply:

   o  If a router is the DR on the interface, the pre-restart network
      LSA for the interface MUST NOT be used to determine
      the previous set of adjacencies.

For the other bullet:

   o  If a router is in state DROther on the interface, it MUST consider
      an adjacency to non-DR and non-BDR neighbors as reestablished when
      the neighbor state reaches 2-Way.

"Considering" is not the requirement. In fact, I suspect this is not a requirement at all, but rather a definition. I think this works better:

   o  If a router is in state DROther on the interface, an adjacency
      to non-DR and non-BDR neighbors is reestablished when
      the neighbor state reaches 2-Way.

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2012-10-29 for -05)
No email
send info
Apologies for the delay.  I've cleared.