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 >> >> >> >> >>> >>>>>> 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". >>>> >>> > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
