Subject: [sfc] Murray Kucherawy's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Thu, 07 May 2020 11:07:59 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-sfc-oam-framework-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for engaging my DISCUSS question about Section 3.1.1.  I don't feel
it was fully resolved, but I also don't feel there's anything to be gained by
pressing my point further.

My original comments:

I think this is pretty well done.  I had little trouble following it and this
is my first foray into the realm of SFC.

I find myself almost suggesting that you don't need the BCP 14 boilerplate or
its language at all in this document.  You barely use it, and it might not even
be needed in the places you do have it especially since this is a framework
document and not a protocol document.

Finally, lots of editorial stuff:

Section 2:
* “In Figure 1, the service layer element such as …” -- s/element/elements/
* “The underlay network may comprise of …” -- s/comprise/consist/, or
alternatively, s/comprise of/comprise/ * “... nodes but not shown …” -- remove
“but”, or s/but/but these/

Section 3, all three numbered list entries:
* “... applicable at this component includes …” -- s/includes/include/

Section 3.1.1:
OLD:
"SF availability is an aspect that raises an interesting question -- How to
determine that a service function is available?." NEW: "SF availability is an
aspect that raises an interesting question: How does one determine that a
service function is available?"

* “... the packet did indeed get the got expected service.”  -- remove “got”
* This section uses both “a SF” and “an SF”.  I don’t know which one is
grammatically correct, but we should find out and use that. Or, if both are,
pick one and be consistent.

Section 3.2.1:
* “An SFC could be comprised of …” -- either remove “of”, or use “composed of”

Section 3.3:
* Either capitalize “Classifier” generally, or not at all.

Section 3.4:
* What constitutes an availability check of the underlay network?  You
discussed this in 3.1.1, but not here.  If this is covered in Section 4.1, a
forward reference would be helpful here.

Section 3.5:
* “... and are mostly transparent …” -- s/are/is/; “network” is singular
* What constitutes an availability check of the overlay network?

Section 4:
* “...for more than one SFC components.”  -- use “component”, or change “more
than one” to “multiple”

Section 4.1:
* “Verify any packet re-ordering and corruption.” -- perhaps “detect” would be
better than “verify” here

Section 4.2:
* “Ability to provision continuity check …” -- put an “a” before “continuity”
* “... supported by continuity function are as follows:” --
s/function/functions/

Section 4.3:
* “... from every transit devices …” -- s/devices/device/
* “Ability to trigger action from …” -- s/action/an action/

Section 5.1:
* I would quote “ping” and “trace”.
* “Table 3 below is not exhaustive” -- needs a period at the end
* Table 3 needs a bit of tidying in terms of alignment.

Section 6.1:
* “... network layer must mark the packet …” -- why isn’t that a MUST?

Section 6.2:
* “... skipping an SF might have implication …” -- s/implication/implications/
* “Any SFC-aware node that initiates an OAM packet must set …” -- why isn’t
that a MUST?

Section 6.3:
* “... indicates it as OAM packet …” -- s/as/as an/

Section 6.4.1:
* “[RFC0792] and [RFC4443] describes …” -- s/describes/describe/
* “... verify the availability of SF or SFC.” -- s/SF/an SF/
* “... can generate ICMP echo …” -- s/ICMP/an ICMP/
* “... from last SFF and thereby …” -- add comma after “SFF”
* “Alternately, …  Alernatively, … ” -- use “Alternatively” for the first one,
and “or” for the second, all in one sentence

Section 6.4.2:
* “[RFC5880] defines Bidirectional …” -- s/defines/defines the/
* “... to perform continuity function …” -- “functions”, or “the continuity
function” * “... value as last SFF …” -- s/last/the last/ * “... with relevant
DIAG code.” -- s/with/with the/  (or “a”)

Section 6.4.3:
* “... transported using NSH header.” -- s/using/using the/

Section 6.4.4:
* “... is implemented in Open Daylight and available.”  -- s/and/and is/

Section 7:
* Table 4 needs some work on spacing consistency.

Section 8:
* “... are applicable for this document.” -- s/are/is/, as “consideration” is
singular * “The OAM information from service layer …” -- s/from/from the/ *
“... service function paths etc.” -- s/paths etc./paths, etc./ * “...
information from SFC layer raises a need for careful security considerations”
-- s/from/from the/, and the sentence is missing a period * “... SFC and SF OAM
may provide mechanism …” -- s/mechanism/mechanisms/ * “... the OAM solution for
SF component should …” -- s/component/components/