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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Tue, 11 Aug 2020 22:45:14 -0700

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?

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 12 Aug 2020 13:37:09 +0000

Hi Murray,

Thanks for your review and comments.
Responses are implemented in the working version.

Al

> -----Original Message-----
> From: Murray Kucherawy via Datatracker [mailto:[email-masked]]
> Sent: Wednesday, August 12, 2020 1:45 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Brian Trammell <[email-masked]>
> Subject: Murray Kucherawy's No Objection on draft-ietf-ippm-route-09:
> (with COMMENT)
> 
...
[acm] 
Ok, I re-titled Section 3 "Route Metric Specifications".
A new Section 3.1 is "Terms and Definitions", and contains the list in former 3.0.

> you're doing is trying to introduce a label "C" to define the class of
> packet types in this context, 
[acm] 
We're not introducing new terminology for IPPM (the IPPM Framework RFC 2330 did that).
Most recently, we developed the concept further in RFC 8468, which is an update to the 2330 Framework. So this should be familiar terminology to the IETF measurement community by now.
Also, there is a generation (or two) of Internet Engineers wondering, "what are these gray-beards talking about?" given that CIDR was introduced in 1993.

> so maybe:
[acm] 
Here's the revised sentence I propose:
NEW NEW
A route that treats equally a class of different types of packets, designated "C" (unrelated to address classes of the past) [RFC2330] [RFC8468].

> 
> Section 3.1 starts with something that isn't a sentence.  I suggest making
> it one.
[acm] 
ok
NEW
The formal name of the metric is:

   Type-P-Route-Ensemble-Method-Variant 

abbreviated as Route Ensemble.

> 
> 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
[acm] 
Remember our definition of "class C". Different types of packets (what we call Type-P in IPPM) can satisfy the testing requirements, but the specifications of class C must be known.