Subject: [mpls] Benjamin Kaduk's No Objection on draft-ietf-mpls-spl-terminology-05: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 18 Jan 2021 11:51:29 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mpls-spl-terminology-05: 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-mpls-spl-terminology/

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

A nice solid and well-written document; thanks.  Just nit-level quibbles
from me...

Section 3

What is the expansion of the "cSPL" term used in Figure 2?
It does not seem to be mentioned anywhere in the prose.

Section 5

   The document describes the terminology to be used when describing and
   specifying the use of SPLs.  It does not effect the forwarding in the
   MPLS data plane, [...]

(nit) I think we want "affect" with an "a" (though the statement is
arguably more true with the "e" version; keep reading).
Also, my instinctive response to absolute statements like "does not
affect" is to seek even the smallest of counterexamples; we do seem to
(in Section 4) now mandate that processing XL followed by 7 at the top
of the stack be "drop the packet", and it was not fully clear to me
whether that was specifically mandated in the RFC 7274 procedures (or
even whether there is something useful to do with such a packet other
than "drop" in the first place).

Section 6

   IANA is requested to change the name of the registry that today is
   called "Special-Purpose MPLS Label Values" is changed to "Base
   Special- Purpose MPLS Label Values".

(nit) The "requested to change [...] is changed to" seems wonky, but
this has to get rewritten by the RFC Editor anyway once IANA has made
the change, so it may not be worth messing with now.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 20 Jan 2021 13:14:55 +0800

Benjamin,

Inline please.

> https://datatracker.ietf.org/doc/draft-ietf-mpls-spl-terminology/

In section 3 of version -03 of the working group document we had the 
following entry:

    o  The combination of the Extension Label (XL) (value 15 which is a
       bSPL, but that is also called xSPL) and an eSPL is called a
       Composite Special Purpose Label (cSPL).

It was removed in later versions. I did not notice.

I think we should either

- put it back; or
- remove the the cSPL in figure 2

Since there are situations where we may need to talk about write 
descriptions where composite SPLs will be used, I think we should put it 
back, but this is not a strong opinion and if I'm in the rough I can 
live with it being removed.
-
> than "drop" in the first place).

I have long given up understanding the difference between affect and 
effect, but I think this is close to correct

If I increase the the speed when driving it will effect the time it 
takes to reach the destination, time will be shorter.

and

If I increase the the speed when driving it will affect my passengers, 
they will feel more uncomfortable.

If that is correct I think it should be "effect in the sentence above; 
if it is wrong I will not discuss it further but let the native English 
speakers that often have very different opinions on effect/affect 
discuss until the RFC Editor call consensus.
>     Special- Purpose MPLS Label Values".

hmmm, this comment is correct

text in version -03

    We request that the name of the IANA registry that today is called
    "Special-Purpose MPLS Label Values" is changed to "Base Special-
    Purpose MPLS Label Values".

Which is in some sense correct, but someone wanted to change to:

      IANA is requested to change the name of the registry that today is
      called "Special-Purpose MPLS Label Values" to "Base
      Special- Purpose MPLS Label Values".

When updating the document I erroneously did not follow through with the 
entire update and it came out as:

SO the new text should be:

NEW TEXT

      IANA is requested to change the name of the registry that today is
      called "Special-Purpose MPLS Label Values" to "Base
      Special- Purpose MPLS Label Values".

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 Jan 2021 12:56:47 -0800

Hi Loa,

Inline as requested!

>        Composite Special Purpose Label (cSPL).

Ah, that makes sense.

> live with it being removed.

Either option works for me, and the expectation of future need to talk
about them makes sense to me, so if we don't hear anything else that would
be my recommendation.

> they will feel more uncomfortable.

Hmm, I think both of them should be "affect".  My two mental rules are that
the meanings "swap" (not exactly) when considering the noun and verb forms
(!!!), and that the verb form of "effect" is roughly synonymous with
"effectuate", i.e., bring about.  I am sure there exist languages more
bizarre than English, but I don't know any :)

> discuss until the RFC Editor call consensus.

I am happy to leave it for the RFC Editor to decide, if we are collectively
uncertain here.

>       Special- Purpose MPLS Label Values".

Sounds god.   Thanks!

-Ben