Subject: [bess] Barry Leiba's No Objection on draft-ietf-bess-nsh-bgp-control-plane-13: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Tue, 17 Dec 2019 21:50:07 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-bess-nsh-bgp-control-plane-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-bess-nsh-bgp-control-plane/

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

— Section 1.2 —

   o  Service Function Overlay Network.  The logical network comprised
      of Classifiers, SFFs, and SFIs that are connected by paths or
      tunnels through underlay transport networks.

You use “comprises” correctly four other times in the document, but this one is
incorrect: “comprised of” should instead be either “comprising” or “composed
of”.  I only bother mentioning it because it’s right the four other times.

— Section 3.1 —

   The Service Function Type identifies the functions/features of
   service function can offer, e.g., classifier, firewall, load
   balancer, etc.

Should this be “a service function”, rather than “of service function”?  And a
nit: you don’t need both “e.g.” and “etc.” together: either one will do on its
own.

— Section 3.2.1 —

   o  The errors listed above are treated as follows:

      1., 2., 6., 7.:  The attribute MUST be treated as malformed and
         the "treat-as-withdraw" approach used as per [RFC7606].

      3.:  Unknown TLVs SHOULD be ignored, and message processing SHOULD
         continue.

      4.:  Treated as a malformed message and the "treat-as-withdraw"
         approach used as per [RFC7606]

Why is 4 not included in the 1,2,6,7 group?  It seems odd to separate it and
not to make it “MUST”, like the others.

— Section 9 —

   Service Function Chaining provides a significant attack opportunity:
   packets can be diverted from their normal paths through the network,
   can be made to execute unexpected functions, and the functions that
   are instantiated in software can be subverted.

The second item in the list appears to lack a subject: <what?> can be made to
execute unexpected functions.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 18 Dec 2019 15:42:08 -0000

Hello Barry,

Thanks for the comments.

> of”.  I only bother mentioning it because it’s right the four other times.

I just consulted an English copy editor who says "comprised of" is correct. Let's leave this to the RPC to apply house style.

> Should this be “a service function”, rather than “of service function”?  And a

Yes. Good catch.

> nit: you don’t need both “e.g.” and “etc.” together: either one will do on its

<Red face emoticon>

> not to make it “MUST”, like the others.

IDR was very specific about how we treated error cases. We tried to comply with what they wanted to see.

4 cannot be parsed further and already has 7606 describing it, so it was appropriate to pull it out separately. In practice, item 4 is not defining new behaviour: such issues will be treated as malformed by definition so (arguably) using 2119 language is inappropriate as we are not defining this behaviour.

But, making 4 say "MUST be treated as described in RFC 7606" seems reasonable.

> execute unexpected functions.

Ah, yes. Originally it was going to be three things applying to packets. We will fix it.

Cheers,
Adrian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 18 Dec 2019 10:51:41 -0500

Thanks, Adrian, for addressing my comments.  All good.

Barry