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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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.