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

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

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" <[e-mail]>
> 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:[e-mail]]
>>>> Sent: Monday, August 08, 2016 5:02 PM
>>>> To: Brian E Carpenter <[e-mail]>;
>>>> draft-ietf-ospf-two-
>>>> [e-mail]; General Area Review Team <[e-mail]>
>>>> 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" <[e-mail]>
>>>> 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" <[e-mail]>
>>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>>> 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 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 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".
>>>>>>
>>>>>
>>>
>>
>