Thanks Adrian for your replying. Yes, I check the abbreviations again, indeed, all of them are introduced in the document. So I think your feedback already address my comments :) Best Regards! -Michael -----邮件原件----- 发件人: Adrian Farrel [mailto:adrian@xxxxxxxxxxxx] 发送时间: 2018年1月30日 16:49 收件人: wangzitao <wangzitao@xxxxxxxxxx>; ops-dir@xxxxxxxx 抄送: draft-farrel-sfc-convent.all@xxxxxxxx; ietf@xxxxxxxx; sfc@xxxxxxxx 主题: RE: Opsdir last call review of draft-farrel-sfc-convent-05 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@xxxxxxxx] On Behalf Of Zitao Wang > Sent: 30 January 2018 00:16 > To: ops-dir@xxxxxxxx > Cc: draft-farrel-sfc-convent.all@xxxxxxxx; ietf@xxxxxxxx; sfc@xxxxxxxx > 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.