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

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Murray,

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

Al

> -----Original Message-----
> From: Murray Kucherawy via Datatracker [mailto:[e-mail]]
> Sent: Wednesday, August 12, 2020 1:45 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Brian Trammell <[e-mail]>
> Subject: Murray Kucherawy's No Objection on draft-ietf-ippm-route-09:
> (with COMMENT)
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-ippm-route-09: No Objection
> 
...
> 
> ----------------------------------------------------------------------
> 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.
[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.

> 
> 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, 
[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:
> 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".
[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
> nodes not conforming to these SHOULDs malfunctioning, misconfigured, or simply
> opting out?
> 
[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.

>