Reviewer: Tim Chown Review result: Has Nits Hi, 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. This document describes an OAM reference framework for Service Function Chaining (SFC), including an overview, functional requirements, applicability of tools and a gap analysis. Overall, I would say that the document is close to being Ready, but has some minor issues and (a lot of) nits to be checked and resolved. General comments: The general writing style is OK, but there are several (tens of) grammatical errors, most notably missing (in)definite articles. While the RFC Editor would catch these, it would be good to clear them up to minimise the workload on the Editor. I’m surprised we’re at v13 and these haven’t been caught before. The document includes the (new) RFC 2119 statement, but oddly then doesn’t use RFC 2119 language in the requirements section. I was also reading the BIER OAM requirements draft recently, where 2119 language is used. Given the document uses the language elsewhere, it should be consistent one way or the other. I looked at RFC 7665, which defines the SFC architecture. It has an OAM section, 5.7, which could be cited in this document, but more importantly it would be good to check that the text there is in sync and covered by this draft. For example, this draft doesn’t really go into any detail on the in-band and out-of-band architecture parts mentioned in the RFC. Also, certain capabilities in the last paragraph of section 5.7 are not mentioned here, e.g., locking of service functions, or support for vendor-specific or experimental functions. It would be nice if this draft ticked off all the items mentioned in 5.7. Nits: Section 1.2.1 I’d split the SFC acronyms from the non-SFC. While the first five are explained in section 1.4 of RFC 7665 (which could be cited), NSH is not; some explanation would be welcomed (indeed RFC 7665 mentions NSG once, without expanding or explaining the term). Section 2 Examples are given of the underlay and link layers, but not the overlay layer. Can one be added? Section 3.1.1 What is meant by “availability” here, vs “liveness” and “fault detection and isolation” in RFC 7665 section 5.7? “the got expected” -> “the expected” Delete “: lack of extendability” ? Not sure what it means here. Could also say, as per RFC 7665, that application-level OAM is out of scope too (as well as validation tools). 3.4 “Perform availability” -> “perform an availability” 3.5 “And are mostly” -> “and is mostly” Section 4: Should be titled SFC OAM Functional Requirements ? And here I’d expect requirements to be MUST, SHOULD or MAY, as per the BIER OAM example I mentioned. Or if not, some text to be added about relative importance (or not). “One SFC components” -> “one SFC component” 4.2 “Provision continuity” -> “provision a continuity” 4.3 “Trigger action” -> “trigger an action” 5.1 “Check and” -> checks and” 6.1 “With necessary” -> “with the necessary” “As OAM” “as an OAM” 6.2 “If it does” -> “if they do” “Packet to an” -> “packets to an” “Have implication” -> “have an implication” 6.3 “Intended to or” -> intended or” 6.4.1 “Describes the” -> “describe the” “Its explains” -> “They explain” “For connectivity” -> “for the connectivity” “From relevant” -> “from the relevant” “Generate ICMP” -> “generate an ICMP” “In NSH” -> “in the NSH” “From last” -> “from the last” 6.4.2. “Defines” -> “defines a” “Mechanism of using” -> “form of” “Perform continuity” -> “perform the continuity” “For SF” -> “for an SF” “As last” -> “as the last” “In NSH” -> “in the NSH” 6.4.3 “Using NSH” -> “using the NSH” “With O” -> “with the O” 6.4.4 Should we cite an expired draft? Is it still being worked on? Section 8 “From service” -> “from the service” “From SFC” -> “from the SFC” “Any internal attacks” -> “an internal attack” “Mechanism for” -> “mechanisms for” “Component should” -> “components should” “The SF .” -> “the SF.” -- Tim -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
