[Gen-art] Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-05

[Brian E Carpenter <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ospf-two-part-metric-05.txt
Reviewer: Brian Carpenter
Review Date: 2016-08-07
IETF LC End Date: 2016-08-15
IESG Telechat date:

Summary: Almost ready
--------

Major issues:
-------------

> Updates: 2328, 5340 (if approved)

If that is so, the text needs to explain what is changed in those two RFCs. Since
this draft describes an "optional extension" to OSPF, it does not obviously update
them. Is any text in those two RFCs made invalid by this draft?

> 3.6.  SPF Calculation
>
>   During the first stage of shortest-path tree calculation for an area,
>   when a vertex V corresponding to a Network-LSA is added to the
>   shortest-path tree and its adjacent vertex W (joined by a link in V's
>   corresponding Network LSA), the cost from V to W, which is W's
>   network-to-router cost, is determined as follows:

I can't parse that sentence. If we delete the subordinate clauses, we get

  When a vertex V is added to the shortest-path tree and its adjacent vertex W,
  the cost from V to W is determined as follows:

What does that mean? What does "its" refer to? Is W adjacent to V, or is W adjacent
to the existing tree? Is W added to the tree before V, or is V added before W?
If I was coding this, I'd have no idea what to do.

> 3.7.  Backward Compatibility

This calls for a Router Functional Capability Bit assignment under RFC 7770.
The bit number should be given as (say) TBD1 not as 0.

> 4.  IANA Considerations

The IANA considerations ask for four assignments. These should be specified as TBD1,
TBD2, TBD3, TBD4 and the TBDs elsewhere in the text should be updated correspondingly.
Also, please reference the relevant RFCs (7770 and whatever defines the Sub-TLV registries.)

Finally, to put this on the standards track, I would really expect to see
an Implementation Status section (RFC 7942). Has this been tested?

Minor issues:
-------------

Please check the three occurrences of lower-case "must" in Section 3. Should they be "MUST"?

> 5.  Security Considerations
>
>   This document does not introduce new security risks.

That's easy to say but hard to prove. Shouldn't you at least refer to the security
considerations of OSPFv2 and OSPFv3?

Also, does section 3.7 introduce a new risk whereby a rogue router could flap its
Two-Part Metric bit on and off, causing all its OSPF peers to continually recalculate
their routes?

Nits:
-----

> Requirements Language

It's unusual to put this at the front. The normal place is after the Introduction.

>  This document may contain material from IETF Documents or IETF
>  Contributions published or made publicly available before November
>  10, 2008. ...

Why is this needed? What did you copy from an old document?

> 0 OSPF Two-part Metric [TPM]

The abbreviation TPM is defined but not used, so why bother? Also, s/[TPM]/(TPM)/ to
avoid confusion with a reference.

> routes w/o considering any network-to-router costs.

Just say "without".