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

[Loa Andersson <[e-mail]>]

Benjamin,

Inline please.

On 19/01/2021 03:51, Benjamin Kaduk via Datatracker wrote:
> 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.

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.
-
> 
> 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).

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.
> 
> 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".

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:


      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".

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

> 
> (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.
> 
> 
> 

-- 

Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]