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

[Brian E Carpenter]

On 10/08/2016 14:09, Acee Lindem (acee) wrote:
> Hi Brian, 
> I believe we got a warning from xml2rfc when we didn’t use the pre-2008
> disclaimer (since the draft “updates” RFC 2328).

That's correct, it generates such a warning, but it's more in the form
of a question ("do you need this?" not "you need this!"). It's confusing.
Most times, it's not needed.

I was in at the birth of that waiver; it drove me nuts that we had to allow
for it.

   Brian

> Thanks,
> Acee 
> 
> On 8/8/16, 6:32 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
> wrote:
> 
>> Hi,
>>
>> That's all good. With the clarifcations, I think the "Updates" is OK too.
>> I still don't think you need the pre-2008 disclaimer, but that's a nit.
>>
>> Thanks
>>   Brian
>>
>> On 09/08/2016 09:27, Jeffrey (Zhaohui) Zhang wrote:
>>> Please see -07 version that should address the issues raised by Brian
>>> (except that "update" part).
>>>
>>> https://tools.ietf.org/html/draft-ietf-ospf-two-part-metric-07
>>>
>>> Thanks.
>>> Jeffrey
>>>
>>>> -Original Message-
>>>> From: Acee Lindem (acee) [mailto:a...@cisco.com]
>>>> Sent: Monday, August 08, 2016 5:02 PM
>>>> To: Brian E Carpenter <brian.e.carpen...@gmail.com>;
>>>> draft-ietf-ospf-two-
>>>> part-metric@ietf.org; General Area Review Team <gen-art@ietf.org>
>>>> Subject: Re: Gen-ART Last Call review of
>>>> draft-ietf-ospf-two-part-metric-
>>>> 05
>>>>
>>>> Hi Brian,
>>>>
>>>> See one inline.
>>>>
>>>> On 8/8/16, 4:18 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Acee,
>>>>>
>>>>> Thanks, just a few points in line:
>>>>>
>>>>> On 09/08/2016 05:47, Acee Lindem (acee) wrote:
>>>>>> Hi Brian,
>>>>>>
>>>>>> Thanks much for the thorough review. Jeffrey and I discussed your
>>>>>> comments
>>>>>> this morning. See responses to your major/minor comments below. We
>>>>>> will
>>>>>> incorporate all the nits.
>>>>>>
>>>>>> On 8/6/16, 9:38 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 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?
>>>>>>
>>>>>> This has been an ongoing debate as to whether an RFC the augments an
>>>>>> existing draft updates it or whether it must actually change the
>>>>>> existing
>>>>>> behavior. In this case, the SPF calculation is modified as specified
>>>>>> in
>>>>>> section 3.6 but only when the new Network-to-Router metric is
>>>>>> advertised.
>>>>>> In RFC 2328 and RFC 5340, this cost is always zero (i.e., cost to
>>>>>> reach
>>>>>&

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

[Acee Lindem (acee)]

Hi Brian, 
I believe we got a warning from xml2rfc when we didn’t use the pre-2008
disclaimer (since the draft “updates” RFC 2328).
Thanks,
Acee 

On 8/8/16, 6:32 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
wrote:

>Hi,
>
>That's all good. With the clarifcations, I think the "Updates" is OK too.
>I still don't think you need the pre-2008 disclaimer, but that's a nit.
>
>Thanks
>   Brian
>
>On 09/08/2016 09:27, Jeffrey (Zhaohui) Zhang wrote:
>> Please see -07 version that should address the issues raised by Brian
>>(except that "update" part).
>> 
>> https://tools.ietf.org/html/draft-ietf-ospf-two-part-metric-07
>> 
>> Thanks.
>> Jeffrey
>> 
>>> -Original Message-
>>> From: Acee Lindem (acee) [mailto:a...@cisco.com]
>>> Sent: Monday, August 08, 2016 5:02 PM
>>> To: Brian E Carpenter <brian.e.carpen...@gmail.com>;
>>>draft-ietf-ospf-two-
>>> part-metric@ietf.org; General Area Review Team <gen-art@ietf.org>
>>> Subject: Re: Gen-ART Last Call review of
>>>draft-ietf-ospf-two-part-metric-
>>> 05
>>>
>>> Hi Brian,
>>>
>>> See one inline.
>>>
>>> On 8/8/16, 4:18 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
>>> wrote:
>>>
>>>> Hi Acee,
>>>>
>>>> Thanks, just a few points in line:
>>>>
>>>> On 09/08/2016 05:47, Acee Lindem (acee) wrote:
>>>>> Hi Brian,
>>>>>
>>>>> Thanks much for the thorough review. Jeffrey and I discussed your
>>>>> comments
>>>>> this morning. See responses to your major/minor comments below. We
>>>>>will
>>>>> incorporate all the nits.
>>>>>
>>>>> On 8/6/16, 9:38 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> 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?
>>>>>
>>>>> This has been an ongoing debate as to whether an RFC the augments an
>>>>> existing draft updates it or whether it must actually change the
>>>>> existing
>>>>> behavior. In this case, the SPF calculation is modified as specified
>>>>>in
>>>>> section 3.6 but only when the new Network-to-Router metric is
>>>>> advertised.
>>>>> In RFC 2328 and RFC 5340, this cost is always zero (i.e., cost to
>>>>>reach
>>>>> all routers connected to the network is solely the outgoing metric
>>>>> metric
>>>>> or Router-to-Network metric).
>>>>
>>>> OK, fair comment.
>>>>
>>>>>
>>>>> I, for one, would be very happy to have consensus of precisely what
>>>>> constitutes update to an existing RFC.
>>>>
>>>> So would many people, and since it affects all RFC streams, not just
>>>>the
>>>> IETF stream, I happen to know that the RFC Editor is working on
>>>> definitions
>>>> for both "updates" and "obsoletes".
>>>>
>>>>> If we don’t up

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

[Brian E Carpenter]

Hi,

That's all good. With the clarifcations, I think the "Updates" is OK too.
I still don't think you need the pre-2008 disclaimer, but that's a nit.

Thanks
   Brian

On 09/08/2016 09:27, Jeffrey (Zhaohui) Zhang wrote:
> Please see -07 version that should address the issues raised by Brian (except 
> that "update" part).
> 
> https://tools.ietf.org/html/draft-ietf-ospf-two-part-metric-07
> 
> Thanks.
> Jeffrey
> 
>> -Original Message-
>> From: Acee Lindem (acee) [mailto:a...@cisco.com]
>> Sent: Monday, August 08, 2016 5:02 PM
>> To: Brian E Carpenter <brian.e.carpen...@gmail.com>; draft-ietf-ospf-two-
>> part-metric....@ietf.org; General Area Review Team <gen-art@ietf.org>
>> Subject: Re: Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-
>> 05
>>
>> Hi Brian,
>>
>> See one inline.
>>
>> On 8/8/16, 4:18 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
>> wrote:
>>
>>> Hi Acee,
>>>
>>> Thanks, just a few points in line:
>>>
>>> On 09/08/2016 05:47, Acee Lindem (acee) wrote:
>>>> Hi Brian,
>>>>
>>>> Thanks much for the thorough review. Jeffrey and I discussed your
>>>> comments
>>>> this morning. See responses to your major/minor comments below. We will
>>>> incorporate all the nits.
>>>>
>>>> On 8/6/16, 9:38 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
>>>> wrote:
>>>>
>>>>> 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?
>>>>
>>>> This has been an ongoing debate as to whether an RFC the augments an
>>>> existing draft updates it or whether it must actually change the
>>>> existing
>>>> behavior. In this case, the SPF calculation is modified as specified in
>>>> section 3.6 but only when the new Network-to-Router metric is
>>>> advertised.
>>>> In RFC 2328 and RFC 5340, this cost is always zero (i.e., cost to reach
>>>> all routers connected to the network is solely the outgoing metric
>>>> metric
>>>> or Router-to-Network metric).
>>>
>>> OK, fair comment.
>>>
>>>>
>>>> I, for one, would be very happy to have consensus of precisely what
>>>> constitutes update to an existing RFC.
>>>
>>> So would many people, and since it affects all RFC streams, not just the
>>> IETF stream, I happen to know that the RFC Editor is working on
>>> definitions
>>> for both "updates" and "obsoletes".
>>>
>>>> If we don’t update the existing
>>>> RFCs, we would avoid the pre-2008 IPR language.
>>>
>>> That doesn't seem right. You only need that language if you are updating
>>> whole chunks of older text. If you take a paragraph from a pre-2008
>>> document,
>>> change a few words, and patch it into the new document, you need either
>>> the agreement of the original authors or the pre-2008 disclaimer. But I
>>> don't think you're doing that in this case, are you?
>>
>> No. We are simply using the context of the existing SPF calculation to
>> describe the additional function.
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>>
>>

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

[Brian E Carpenter]

Hi Acee,

Thanks, just a few points in line:

On 09/08/2016 05:47, Acee Lindem (acee) wrote:
> Hi Brian, 
> 
> Thanks much for the thorough review. Jeffrey and I discussed your comments
> this morning. See responses to your major/minor comments below. We will
> incorporate all the nits.
> 
> On 8/6/16, 9:38 PM, "Brian E Carpenter" 
> wrote:
> 
>> 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
>> .
>>
>> 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?
> 
> This has been an ongoing debate as to whether an RFC the augments an
> existing draft updates it or whether it must actually change the existing
> behavior. In this case, the SPF calculation is modified as specified in
> section 3.6 but only when the new Network-to-Router metric is advertised.
> In RFC 2328 and RFC 5340, this cost is always zero (i.e., cost to reach
> all routers connected to the network is solely the outgoing metric metric
> or Router-to-Network metric).

OK, fair comment.

> 
> I, for one, would be very happy to have consensus of precisely what
> constitutes update to an existing RFC. 

So would many people, and since it affects all RFC streams, not just the
IETF stream, I happen to know that the RFC Editor is working on definitions
for both "updates" and "obsoletes".

> If we don’t update the existing
> RFCs, we would avoid the pre-2008 IPR language.

That doesn't seem right. You only need that language if you are updating
whole chunks of older text. If you take a paragraph from a pre-2008 document,
change a few words, and patch it into the new document, you need either
the agreement of the original authors or the pre-2008 disclaimer. But I
don't think you're doing that in this case, are you?

>>> 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.
> 
> You really do have to look at RFC 2328 to understand it. 

Yes, I did that in some detail when I was teaching routing a few years ago ;-)

> Does this
> modified text parse better?
> 
> The first stage of the shortest-path tree calculation is described
> in section 16.1 of [RFC 2328] and modified for OSPFv3 as described in
> section 4.8.1 of [RFC 5340]. When a vertex V corresponding to a
> Network-LSA
> has just been added to the Shortest Path Tree (SPT) and an adjacent
> vertex W 
> (joined by a link in V’s corresponding Network-LSA) is being added to
> the SPT, the cost from V to W (W’s network-to-router cost) is
> determined 
> as follows:

MUCH better. It also clarifies the "Updates:" aspect.

Thanks
   Brian

> 
>>
>>> 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.)
> 
> 3.7 and 4 are both fixed in -06 based on comments from Alia.
> 
>>
>> Finally, to put this on the standards track, I would really expect to see
>> an Implementation Status section (RFC 7942). Has this been tested?
> 
> The implementation of this stalled. However, it is viewed by the WG as
> straight-forward enough to advance.
> 
> 
>>
>> Minor issues:
>> -
>>
>> Please check the three 

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

[Acee Lindem (acee)]

Hi Brian, 

Thanks much for the thorough review. Jeffrey and I discussed your comments
this morning. See responses to your major/minor comments below. We will
incorporate all the nits.

On 8/6/16, 9:38 PM, "Brian E Carpenter" 
wrote:

>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
>.
>
>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?

This has been an ongoing debate as to whether an RFC the augments an
existing draft updates it or whether it must actually change the existing
behavior. In this case, the SPF calculation is modified as specified in
section 3.6 but only when the new Network-to-Router metric is advertised.
In RFC 2328 and RFC 5340, this cost is always zero (i.e., cost to reach
all routers connected to the network is solely the outgoing metric metric
or Router-to-Network metric).

I, for one, would be very happy to have consensus of precisely what
constitutes update to an existing RFC. If we don’t update the existing
RFCs, we would avoid the pre-2008 IPR language.


>
>> 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.

You really do have to look at RFC 2328 to understand it. Does this
modified text parse better?

The first stage of the shortest-path tree calculation is described
in section 16.1 of [RFC 2328] and modified for OSPFv3 as described in
section 4.8.1 of [RFC 5340]. When a vertex V corresponding to a
Network-LSA
has just been added to the Shortest Path Tree (SPT) and an adjacent
vertex W 
(joined by a link in V’s corresponding Network-LSA) is being added to
the SPT, the cost from V to W (W’s network-to-router cost) is
determined 
as follows:

>
>> 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.)

3.7 and 4 are both fixed in -06 based on comments from Alia.

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

The implementation of this stalled. However, it is viewed by the WG as
straight-forward enough to advance.


>
>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?

We will add the reference.

>
>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?

This is no more of a risk than other intra-area metric change.

Thanks,
Jeffrey and Acee 




>
>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 

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

[Brian E Carpenter]

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
.

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".

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art