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

[Benjamin Kaduk <[e-mail]>]

Hi Loa,

Inline as requested!

On Wed, Jan 20, 2021 at 01:14:55PM +0800, Loa Andersson wrote:
> 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).

Ah, that makes sense.

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

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.

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

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

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

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

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

Sounds god.   Thanks!

-Ben

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