[ippm] Murray Kucherawy's No Objection on draft-ietf-ippm-route-09: (with COMMENT)

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-ippm-route-09: 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-ippm-route/



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

Section 3's title made me expect a glossary, but it also lays out actual
normative requirements.  This seems odd.  Personal preference, but I suggest
separating them out.   I note that Warren also tripped over this.

Also in Section 3, I tripped over "class C" as Warren did.  But I think what
you're doing is trying to introduce a label "C" to define the class of packet
types in this context, so maybe:

OLD:

    A route that treats equally a class C of different ...

NEW:

    A route that treats equally a class, referred to here as "C", of different
    ...

Then you can just refer to "C" later and drop the confusing references to
"class C".

Section 3.1 starts with something that isn't a sentence.  I suggest making it
one.

Section 4.1 uses SHOULD in a number of places that leave me wondering, "Or else
what?"  You're presenting the implementer with a choice here, but it doesn't
feel like these choices are fully developed.  The same occurs in 4.3.  Are
nodes not conforming to these SHOULDs malfunctioning, misconfigured, or simply
opting out?