I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document provides a new way of communicating connectivity on a shared network.  Currently there are two methods, one used for broadcast/NBMA nets and one used for point-multipoint networks.  The broadcast net case elects a DR that then floods a network LSA noting all routers on the net so that LSA database synchronization uses the DR.  The p2mp case establishes links from each router to each other router on the p2mp network.  The broadcast/NBMA case does not permit different metrics for the links to each router on the broadcast network.  The p2mp case allows different metrics for the links between adjacent routers on the p2mp network.

This draft introduces a hybrid case for broadcast/NBMA networks - using the neighbor discovery and LSA database synchronization of the broadcast/NBMA case but the establishment of links with different metrics of the p2mp case.  The draft specifies changes to LSAs and processing that would produce this hybrid behavior.

The security considerations section says there are no new security vulnerabilities that result.  OSPF authenticates all routers on a shared network (whether broadcast/NBMA or p2mp) with a single shared key, and this mechanism's changes share that authentication.  OSPF does not protect against bad behavior by legitimate participants so no misbehavior possible with these changes would create new vulnerabilities.

The draft introduces changes to the LSAs and behavior but does not explain why the changes are needed or what their intent is.  This makes it very hard to understand or analyze what the effect would be.  I was able to figure out why the a router LSA type 1 link is introduced to a neighbor that is also mentioned by the DR (that's the combination of the broadcast discovery feature into the p2mp links part of the hybrid).  But I was not able to figure out other changes, such as why it was necessary to introduce type 3 stub network links for the router's subnet.  Perhaps the authors expect that readers will be so intimately familiar with OSPF design that the motivation for each change will be obvious.  But it does make readers work hard.

Section 5 considers cases where some routers on a broadcast network follow the hybrid behavior and other follow the broadcast/NBMA behavior.  OSPF works on the assumption that all routers share the same dataset and therefore each will compute shortest paths that will not introduce loops.   In this case, not all routers will be working from the same dataset of links, raising concern about loops.  Section 5 (briefly) says that in this case there would be "no traffic traversing certain pairs of routers" but no loops.   I can understand that enough to believe it.    But I am not as confident that a router that produces both the network LSA and a router LSA with the p2mp links could not confuse the situation sufficiently to produce loops.  I wonder if the authors have considered that case.  I'm sorry that I was not able to devote the time to the shortest path computation to resolve this lack of confidence for myself.

NOTE: this concern would be a case of mis-behavior by a valid participant and OSPF is well understood to be unprotected from such mis-behavior.  This is NOT a newly introduced security concern.

section 4.5 says "the DR MUST NOT generate a network LSA for the interface."  OSPF's specs in general do not recommend reporting errors, or I would suggest a new error report if a network LSA were spotted on an interface that was designated as hybrid.

--Sandy

Nits:

page 3:

   network.  Further, it mandates establishment of adjacencies to all
   all configured or discovered neighbors on the network.

"all all" -> "all"

page 8

   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.

I think there is a separate adjacency for each neighbor, not one for all neighbors, so I think this should be something like:

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