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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]