Subject: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-two-part-metric-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 12 Oct 2016 15:39:43 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-ospf-two-part-metric-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-two-part-metric/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

abstract: the text doesn't really explain anything to me.  But
then I'm not familiar with OSPF so maybe it's obvious to
someone who is.

intro: expanding LSA, VPLS etc on 1st use would be better.

3.1, 2nd bullet: the text here was very unclear to me

(All that said, the satellite/mobile ground station example 
does enough to ensure that the overall document is clear
so the above are nitty nits:-)

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 13 Oct 2016 00:47:54 +0000

Hi Stephen, 

>https://datatracker.ietf.org/doc/draft-ietf-ospf-two-part-metric/

   This document specifies an optional OSPF protocol extension
   to represent router metrics in a multi-access network in two parts: the
   metric from the router to the network and the metric from the network
   to the router.  For such networks, the router to router metric
   for SPF route computation is the sum of the two parts.
   This document updates RFC 2328.

>intro: expanding LSA, VPLS etc on 1st use would be better.

Sure - I guess these are not asterisked in
https://www.rfc-editor.org/materials/abbrev.expansion.txt

>3.1, 2nd bullet: the text here was very unclear to me

Section 3 contains additional variable in the RFC 2328 Interface Data
Structure (section 9). While the description is terse in isolation, I
don’t think that is unclear in the context of this data structure and rest
of the draft. 

Thanks,
Acee