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

"Acee Lindem (acee)" <acee@cisco.com> Mon, 08 August 2016 21:02 UTC

Return-Path: <acee@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9CB12D098; Mon, 8 Aug 2016 14:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Level:
X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnN13ykznQ0L; Mon, 8 Aug 2016 14:02:23 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A32D12B027; Mon, 8 Aug 2016 14:02:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9546; q=dns/txt; s=iport; t=1470690143; x=1471899743; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=aRAlUnmAKOS5QXZtOo9B4mfRGDoDxdKGKv2mhjiYqR0=; b=OhR6D3qzduUuQ6xF360rqryQT3XJPdtNjkNlLX9DcZh1lMeLTEFMI7rH GTm5+Oeaeenjov9FLe/gclq9IWIBhs+IjuprcMAVxeL7t2UOPluJnryvV GoySVts2RGsyj6vS2sOo2hhx7Xcra8gsRGMkYg0OucD8RDWLvFwZleS/c g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAr8qhX/4sNJK1XBoNFVnwHrGyMK?= =?us-ascii?q?IF9JIV5AhyBJDgUAQEBAQEBAV0nhF8BBSMRQBUCAQgUBAICJgICAh8RFRACBAE?= =?us-ascii?q?SiBcDFw6yZ4tfDYQuAQEBAQEBAQEBAQEBAQEBAQEBH4EBiXaBekmBbw4XgmqCW?= =?us-ascii?q?gWIJZBgNAGGHIYygjuBa06EDYdegR+GZIFJhAeDdwEeNoISHIFMbgGGX38BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,491,1464652800"; d="scan'208";a="308338591"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Aug 2016 21:02:22 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u78L2MeK019928 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Aug 2016 21:02:22 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 8 Aug 2016 17:02:19 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 8 Aug 2016 17:02:19 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "draft-ietf-ospf-two-part-metric.all@ietf.org" <draft-ietf-ospf-two-part-metric.all@ietf.org>, General Area Review Team <gen-art@ietf.org>
Thread-Topic: Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-05
Thread-Index: AQHR8Ex8YwoNATto6UeHCLvPFj8HLqA/WTcAgABtZAD//8kMgA==
Date: Mon, 8 Aug 2016 21:02:19 +0000
Message-ID: <D3CE6B15.768D6%acee@cisco.com>
References: <4ee8e895-a939-d747-a82f-fb7c8696b36e@gmail.com> <D3CE3687.7666E%acee@cisco.com> <7b3e0da4-2cf9-d91d-d179-1d6179c0f9b3@gmail.com>
In-Reply-To: <7b3e0da4-2cf9-d91d-d179-1d6179c0f9b3@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8D03AFE518A1F14997AE8E736132A188@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/yihLL0Aa7lwYQE66gMxupGMjK9Q>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2016 21:02:26 -0000

Hi Brian, 

See one inline. 

On 8/8/16, 4:18 PM, "Brian E Carpenter" <brian.e.carpenter@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.carpenter@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".
>> 
>