[RTG-DIR] RtgDir review: draft-ietf-teas-native-ip-scenarios-06
Loa Andersson <loa@pi.nu> Wed, 21 August 2019 19:05 UTC
Return-Path: <loa@pi.nu>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322B3120E8B; Wed, 21 Aug 2019 12:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 FIvx1Gn1Z0VC; Wed, 21 Aug 2019 12:05:17 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102121209AF; Wed, 21 Aug 2019 12:05:14 -0700 (PDT)
Received: from [192.168.0.8] (c83-250-135-99.bredband.comhem.se [83.250.135.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 902CD36337C; Wed, 21 Aug 2019 21:05:11 +0200 (CEST)
To: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, draft-ietf-teas-native-ip-scenarios.all@ietf.org, TEAS WG <teas@ietf.org>
From: Loa Andersson <loa@pi.nu>
Message-ID: <65133e17-0976-231d-65a8-53a49be73174@pi.nu>
Date: Wed, 21 Aug 2019 21:04:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/wFVqFsffFCpN9aVKNiyw8O1yoP4>
Subject: [RTG-DIR] RtgDir review: draft-ietf-teas-native-ip-scenarios-06
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2019 19:05:20 -0000
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-teas-native-ip-scenarios-06 Reviewer: Loa Andersson Review Date: date IETF LC End Date: - Intended Status: Informational I have some minor concerns about this document that I think should be resolved before publication. The concerns might in some cases be considered to be nits. Comments: The document describes scenarios in which CCDR, a technology that combines the advantages or distributed and centralized control, could be deployed. The document also report on testing that has been performed with this technology. Major Issues: No major issues found. This a very interesting and valuable document that should be progressed to RFC. It is refreshing to see an attempt to take advantage of distributed and centralized control technologies and merge them together to a single whole. Minor Issues: I found the document well worth reading and think about, I also found it somewhat hard to read, most of this probably depends on my lack of expertise in the area. However: - I would consider doing a English language review, I don't think there is anything wrong, but the language is sometimes a bit heavy. Sometimes the choice of word could be discussed, in a specification I would rather expect "advantage" rather than "merit". - I'd like to see exactly which specification that has been tested early in the document, preferably in the Introduction. - I would expand the Abstract with one or two paragraphs. When I worked for larger companies, I used to say that the abstract should be written such that my immediate manager could read it and understand what it is all about. Since the abstract is supposed to self-contained and separable from the RFC (see RFC 7997) abbreviations in the abstract is to be avoided (or expanded). - Abbreviations The RFC Editor Abbreviations list (https://www.rfc-editor.org/materials/abbrev.expansion.txt) gives a good idea on the rules that applies to abbreviations in RFCs. The basic rule is that an abbreviation is expanded the first time it is used. In this document there are abbreviations, for example in figures, that is not expanded, e.g. CR, SR, BRAS and IDC - I also have a small concern about listing "alternative" technologies (MPLS-TE, SR and DETNET) in the introduction, it is hard to come away without the impression that these technologies are seen as insufficient. Admittedly they do not solve the problem that CCDR solves, but they are well suited to solve the problem they were designed for. Nits: I'm unclear about nits vs. minor concerns for this document, and listed everything as minor concerns. /Loa PS I'm sorry that this review has been delayed. -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64
- [RTG-DIR] RtgDir review: draft-ietf-teas-native-i… Loa Andersson
- [RTG-DIR] 答复: [Teas] RtgDir review: draft-ietf-te… Aijun Wang