RE: Opsdir last call review of draft-farrel-sfc-convent-05

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 30 January 2018 08:51 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB63131786; Tue, 30 Jan 2018 00:51:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5fDEt7Xemqzf; Tue, 30 Jan 2018 00:50:59 -0800 (PST)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53F6131A20; Tue, 30 Jan 2018 00:49:27 -0800 (PST)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0U8mxA4013787; Tue, 30 Jan 2018 08:48:59 GMT
Received: from 950129200 ([193.57.120.225]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0U8mvnf013756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jan 2018 08:48:58 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Zitao Wang' <wangzitao@huawei.com>, ops-dir@ietf.org
Cc: draft-farrel-sfc-convent.all@ietf.org, ietf@ietf.org, sfc@ietf.org
References: <151727133894.27336.11581082683338694561@ietfa.amsl.com>
In-Reply-To: <151727133894.27336.11581082683338694561@ietfa.amsl.com>
Subject: RE: Opsdir last call review of draft-farrel-sfc-convent-05
Date: Tue, 30 Jan 2018 08:48:57 -0000
Message-ID: <086101d399a7$2b723710$8256a530$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIcpUOq1X79PMrmRdl6Wp93DiGtiaL6AGZw
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23628.006
X-TM-AS-Result: No--7.760-10.0-31-10
X-imss-scan-details: No--7.760-10.0-31-10
X-TMASE-MatchedRID: vEvJ7Rh1lGinykMun0J1wp21GZGE81yGMZm0+sEE9mu1YUw9VHYKvP4Z AUsty2ENjXsFLEEP2YqYmSTfbx/hHjPAnsAORqSfwVaayvK71l/AvdwvBqgdnkavwbe/bczf+QM 79UDZjetNYvDaO9t+nOwJvvRqClGr772W/22r9NiVUcz8XpiS9EDwlkRNC6PCzUFc4X2GObJyJp dgSLwCbqsW9TgXXMGUKNbVyoeR7BOQMCeWVJQ9t/zu9Lw9C7fAUAjrAJWsTe8wplGJ7NxS0y+sl rIoxy6PpSxgXQCmVD4O5jobBvSaVF7QViK5UP9wz5rIW0RbS5g026H7nOZLr3KqW7xVeF20Kgb8 BfqrnGpzrFueZ32PHT4gmzHPr8wbY4qH3z2g5CGM29hkek7Xd30tCKdnhB581B0Hk1Q1KyLUZxE AlFPo846HM5rqDwqtnl32i3qSnBNHKexGZ8cKvlaH0ZSl//thpsfhkQRk2yzlawJRsiWsVA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/WfGmO898KLte-031HJFy0kThYwE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jan 2018 08:51:02 -0000

Thanks for the review Zitao,

I'm disinclined to add a terminology section to a short draft that just defines one code point in a simple increment to RFC 8300.

If we did, we would position it after the Introduction. But I checked, and all of the acronyms and abbreviations (except DCN) are expanded in the Introduction, so we would just be adding repetition.

Additionally, the Introduction also includes...

   This document uses the terms defined in [RFC7665] and
   [I-D.ietf-sfc-nsh].

Nevertheless, if the ADs think this would be helpful, it is easy enough to add. I await their review.

Thanks,
Adrian

> -----Original Message-----
> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Zitao Wang
> Sent: 30 January 2018 00:16
> To: ops-dir@ietf.org
> Cc: draft-farrel-sfc-convent.all@ietf.org; ietf@ietf.org; sfc@ietf.org
> Subject: Opsdir last call review of draft-farrel-sfc-convent-05
> 
> Reviewer: Zitao Wang
> Review result: Ready
> 
> I have reviewed this document as part of the Operational directorate’s ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving the operational aspects of
> the IETF drafts. Comments that are not addressed in last call may be included
> in AD reviews during the IESG review.  Document editors and WG chairs should
> treat these comments just like any other last call comments.
> 
> Document reviewed:draft-farrel-sfc-convent-05
> 
> Summary:
> 
> This document describes the use of the Network Service Header (NSH) in a
> Service Function Chaining (SFC) enabled network with no payload data and
> carrying only metadata.  This is achieved by defining a new NSH "Next Protocol"
> type value of "None". This document illustrates some of the functions that may
> be achieved or enhanced by this mechanism, but it does not provide an
> exhaustive list of use cases, nor is it intended to be definitive about the
> functions it describes.  It is expected that other documents will describe
> specific use cases in more detail and will define the protocol mechanics for
> each use case.
> 
> Major issue: None
> 
> Minor issue: Suggest adding a termnology section to introduce the abbreviations
> which be used in this document, such as SFP, NSH, SF, SFI, etc.