Subject: [ippm] Lars Eggert's Discuss on draft-ietf-ippm-capacity-metric-method-10: (with DISCUSS and COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Tue, 11 May 2021 01:26:54 -0700

Lars Eggert has entered the following ballot position for
draft-ietf-ippm-capacity-metric-method-10: Discuss

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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-metric-method/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

DOWNREF from this Standards Track doc to Informational RFC7497.
I didn't see this called out in the Last Call, and it's also not a document we have
in the DOWNREF registry already.

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

Section 1, paragraph 3, comment:
>    Here, the main use case is to assess the maximum capacity of the
>    access network, with specific performance criteria used in the
>    measurement.

If the main use case is to measure access network paths, that applicability
should be made very explicit, i.e., in the title and abstract.

Section 2, paragraph 2, comment:
>    The scope of this memo is to define a metric and corresponding method
>    to unambiguously perform Active measurements of Maximum IP-Layer
>    Capacity, along with related metrics and methods.

I'm not sure what "unambiguously perform" is meant to express?

Section 2, paragraph 3, comment:
>    A local goal is to aid efficient test procedures where possible, and
>    to recommend reporting with additional interpretation of the results.

What is this goal "local" to - the IETF? Also, I'm unclear what "reporting with
additional interpretation of the results" is supposed to express.

Section 2, paragraph 10, comment:
>    - If a network operator is certain of the access capacity to be
>    validated, then testing MAY start with a fixed rate test at the
>    access capacity and avoid activating the load adjustment algorithm.
>    However, the stimulus for a diagnostic test (such as a subscriber
>    request) strongly implies that there is no certainty and the load
>    adjustment algorithm will be needed.

Since the first sentence of this paragraph uses a RFC2119 MAY, I'd suggest
rephrasing the second sentence to end with "there is no certainty and use of the
load adjustment algorithm is RECOMMENDED."

Section 3, paragraph 4, comment:
>    1.  Internet access is no longer the bottleneck for many users.

What is the bottleneck then, and if it's not the access bandwidth, why is a new
metric for it helpful?

Section 4, paragraph 4, comment:
>    o  Src, the address of a host (such as the globally routable IP
>       address).
>
>    o  Dst, the address of a host (such as the globally routable IP
>       address).

For many hosts, their IP address is not globally routable, and hasn't been for
decades. Or did you mean CPE?

Section 8.1, paragraph 1, comment:
> 8.1.  Load Rate Adjustment Algorithm

I wonder why this section is trying to define a crude new AIMD scheme, when we
have lots of good experience with TCP's AIMD approach, which converges on the
available bandwidth relatively well?

Also, the description of the algorithm itself is far from clear.

Section 8.1, paragraph 7, comment:
>    If the feedback indicates that no sequence number anomalies were
>    detected AND the delay range was below the lower threshold, the
>    offered load rate is increased.  If congestion has not been confirmed
>    up to this point, the offered load rate is increased by more than one
>    rate (e.g., Rx+10).  This allows the offered load to quickly reach a
>    near-maximum rate.  Conversely, if congestion has been previously
>    confirmed, the offered load rate is only increased by one (Rx+1).

The first sentence talks about sequence number anomalies and delay ranges. The
rest of the paragraph then talks about whether congestion and whether it was
confirmed or not. Does this mean that (some amount of) sequence number anomalies
and/or delay indicates congestion? Is that defined somewhere?

Section 8.1, paragraph 7, comment:
>    If the feedback indicates that sequence number anomalies were
>    detected OR the delay range was above the upper threshold, the
>    offered load rate is decreased.  The RECOMMENDED values are 0 for

This doesn't agree with the previous paragraph, which says "Conversely, if
congestion has been previously confirmed, the offered load rate is only
increased by one (Rx+1)." (Or I don't understand the difference between
congestion and sequence number anomalies/delay ranges; see previous comment.)

Section 8.4, paragraph 2, comment:
>    This section is for the benefit of the Document Shepherd's form, and
>    will be deleted prior to final review.

Should this section have been deleted before the IESG review then? Would you
like the IESG to ignore it? You probably also need to instruct the RFC Editor to
remove it before publication?

This document uses RFC2119 keywords, but does not contain the recommended
RFC8174 boilerplate. (It contains some text with a similar beginning.)

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 1, paragraph 5, nit:
-    authors found that a high percentage of paths tested support UDP
+    authors found that a high percentage of paths tested support the UDP
+                                                                 ++++

Section 3, paragraph 8, nit:
-        to less traffic crossing ISP gateways in future.
+        to less traffic crossing ISP gateways in the future.
+                                                 ++++

Section 8.1, paragraph 2, nit:
-    agressiveness (speed of ramp-up and down to the Maximum IP-Layer
+    aggressiveness (speed of ramp-up and down to the Maximum IP-Layer
+     +

Section 8.2, paragraph 5, nit:
-    Another approach comes from Section 24 of RFC 2544[RFC2544] and its
-                                              --------
+    Another approach comes from Section 24 of [RFC2544] and its

Section 8.3, paragraph 4, nit:
-    The path measured may be state-full based on many factors, and the
-                                  -  -
+    The path measured may be stateful based on many factors, and the

Section 14.2, paragraph 5, nit:
-    measurements with a clear and concise rate reduction when warrented,
-                                                                  ^
+    measurements with a clear and concise rate reduction when warranted,
+                                                                  ^

"I", paragraph 2, nit:
>  to the specifications of other Standards Development Organizations (SDO) (t
>                                 ^^^^^^^^^
An apostrophe may be missing.

"S", paragraph 2, nit:
> t Maximum IP-Layer Capacity is unknown (which is sometimes the case; service
>                                        ^
Unpaired symbol: ')' seems to be missing

Section 6.3, paragraph 14, nit:
> urement systems MUST be higher than than the smallest of the links on the pa
>                                ^^^^^^^^^
Possible typo: you repeated a word

Section 6.3, paragraph 15, nit:
> PM list over all dt-length intervals in I. Measurements according to these de
>                                      ^^^^
Did you mean "in me", "in her", "in him", "in us", or "in them"?

Section 8, paragraph 3, nit:
> work, since this is an active test method and it will likely cause congestion
>                                    ^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 8.2, paragraph 4, nit:
> etons (dt = 1 second) has proven to a be of practical value during tests of
>                                     ^^^^
After 'a', do not use a verb. Make sure that the spelling of 'be' is correct.
If 'be' is the first word in a compound adjective, use a hyphen between the two
words. Note: This error message can occur if you use a verb as a noun, and the
word is not a noun in standard English.

Section 8.3, paragraph 4, nit:
> nts based on those packets. Many different traffic shapers and on-demand acce
>                             ^^^^^^^^^^^^^^
Consider using "Many".

Section 8.3, paragraph 6, nit:
> , where packet losses may occur independently from the measurement sending ra
>                                 ^^^^^^^^^^^^^^^^^^
The usual collocation for "independently" is "of", not "from". Did you mean
"independently of"?

Section 10, paragraph 10, nit:
> ffic (for example, the range of I duration values SHOULD be limited). The exa
>                                 ^^^^^^^^^^
Do not use a noun immediately after the pronoun 'I'. Use a verb or an adverb,
or possibly some other part of speech.

"R", paragraph 1, nit:
> ble) seqErr = 0 # Measured count of any of Loss or Reordering impairments de
>                                  ^^^^^^^^^
Consider simply using "of" instead.

Section 14.1, paragraph 10, nit:
> g a test when connectivity is lost for an longer interval (Feedback message o
>                                        ^^
Use "a" instead of 'an' if the following word doesn't start with a vowel sound,
e.g. 'a sentence', 'a university'.

Section 14.2, paragraph 10, nit:
> easurements. A brief review of some of the other SHOULD-level requirements fo
>                                ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

"Authors' Addresses", paragraph 2, nit:
>  200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420
>                                    ^^
Two consecutive commas

"Authors' Addresses", paragraph 5, nit:
>  200 Laurel Avenue South Middletown,, NJ 07748 USA Email: lencia@att
>                                    ^^
Two consecutive commas

---

From: "MORTON JR., AL" <[email-masked]>
Date: Mon, 17 May 2021 18:00:57 +0000

Hi Lars,

Let's resolve your comments and answer your questions. 
Rüdiger [RG] and I [acm] will do our best.  

I have implemented all the resolutions offered below in the working text.

I'm pulling one point out for extra attention (from the DISCUSS):
@@@@ Is the DOWNREF registry an action item for chairs or AD/Martin?

Al

> -----Original Message-----
> From: Lars Eggert via Datatracker <[email-masked]>
> Sent: Tuesday, May 11, 2021 4:27 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; Ian Swett <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Lars Eggert's Discuss on draft-ietf-ippm-capacity-metric-method-
> 10: (with DISCUSS and COMMENT)
> 
...
> I didn't see this called out in the Last Call, and it's also not a
> document we have in the DOWNREF registry already.
[acm] 
Ok, I think this means another IETF Last Call?  It's not the first time
we've been tripped-up by keeping IPPM's Framework+updates and other 
requirements docs off the Standards-Track.

I also think that https://datatracker.ietf.org/doc/html/rfc7497 will figure
prominently in future work on the Capacity topic, such as a test protocol, so we
should add it to the DOWNREF registry.

@@@@ Is the DOWNREF registry an action item for chairs or AD/Martin?

Two things:

1. The term "access" doesn't have a universally agreed definition regarding the portion of the network it covers, and that's partly because there are many architectures in use.

2. If we add access to the title or abstract, we are unnecessarily limiting the scope that we define later. We refer to section of RFC 7497 where the figure includes the subscriber's device, multiple private networks, and various devices and gateways ending at a transit gateway.

So, I don't want to emphasize the term "access" as you propose.
 
Perhaps we can clarify this further in the Intro, because the Scope says:

   The primary application of the metric and method of measurement
   described here is the same as in Section 2 of [RFC7497]...

How about:
Here, the main use case is to assess the maximum capacity of one or more networks
where the subscriber receives specific performance assurances, sometimes 
referred to as the Internet access.

> I'm not sure what "unambiguously perform" is meant to express?

[RG] is it unambiguously measure...? If yes roughly:
"The scope of this memo is to define Active Measurement metrics and corresponding methods
to unambiguously determine Maximum IP-Layer Capacity and useful secondary evaluations."

[acm] With s/evaluations/metrics/ this WFM.

> What is this goal "local" to - the IETF? 
[acm] Yes IETF, but that word choice seems unclear now.

[RG] further s/aid/add??

> Also, I'm unclear what "reporting
> with additional interpretation of the results" is supposed to express.

[acm] Let's try:

Secondary goals are to add considerations for test procedures, and
to provide interpretation of the Maximum IP-Layer Capacity results (to
identify cases where more testing is warranted, possibly with alternate
configurations).

> rephrasing the second sentence to end with "there is no certainty and use
> of the load adjustment algorithm is RECOMMENDED."

[RG] sounds good to me.
[acm] WFM
> What is the bottleneck then, and if it's not the access bandwidth, why is
> a new metric for it helpful?

[RG]+[acm] 1.  Internet access is no longer the bottleneck for many users, but subscribers expect network providers to honor contracted access performance.

[acm] IOW, when you subscribe to a 1 Gbps service, then your ISP, you, and possibly other parties want to assure that performance level is delivered. If you test and confirm the subscribed performance level, then you can seek the location of the bottleneck elsewhere.

> For many hosts, their IP address is not globally routable, and hasn't been
> for decades. Or did you mean CPE?

[acm] I think *host* is general-enough to include CPE that is the source or destination of test packets. Also, "globally routable" is part of an example.

> have lots of good experience with TCP's AIMD approach, which converges on
> the available bandwidth relatively well?

[acm] "crude"?? Our algorithm has the advantage of receiver measurements of rate,
loss, and delay. So, we aren't making inferences based on ACKs, we communicate
measurement feedback instead.

This is not a new AIMD. I'm sure you haven't had time to review
hundreds of test results where we compare our load adjustment algorithm to 
TCP's AIMDs when seeking to measure the maximum IP-layer capacity.

Please see section 4 of https://datatracker.ietf.org/doc/html/rfc8337
particularly the list of section 4.1 where Matt Mathis wrote:

   o  TCP is a control system with circular dependencies -- everything
      affects performance, including components that are explicitly not
      part of the test (for example, the host processing power is not
      in-scope of path performance tests).

and this is similar to the statements I have heard for >20 years in IETF,
where the conclusion is that TCP was not designed as a measurement tool.

So, it was a goal to avoid the limitations of TCP (windows, ACK feedback, 
retransmissions, and the CCA that were available, including BBR and BBRv2).
The algorithm we defined is intended to be fast, adjustable in straightforward 
ways, and (most important to Magnus) not to be deployed as a general-purpose
CCA in TCP. Our scope is infrequent, diagnostic measurements.

> Also, the description of the algorithm itself is far from clear.

[acm] 
We added the pseudocode in case some readers weren't satisfied with the text,
and let's see what we can clarify with respect to your specific comments below.

> The first sentence talks about sequence number anomalies and delay ranges.
> The rest of the paragraph then talks about whether congestion and whether it
> was confirmed or not. Does this mean that (some amount of) sequence number
> anomalies and/or delay indicates congestion? Is that defined somewhere?

[acm] Yes, in a paragraph that begins:
     Lastly, the method for inferring congestion is that there were...

I'll add a forward reference:
     ... If congestion has not been confirmed up to this point (see below 
     for the method to declare congestion), the offered load rate is increased ...
> congestion and sequence number anomalies/delay ranges; see previous

[acm]  Your "(Or ...)" is correct, we deferred the description of congestion
declaration to a later paragraph, where we require 2 feedback messages at least:

    Lastly, the method for inferring congestion is that there were sequence 
    number anomalies AND/OR the delay range was above the upper threshold 
    for two consecutive feedback intervals. ...

> Should this section have been deleted before the IESG review then? Would
> you like the IESG to ignore it? 

[acm] I think that during the February review, that's exactly what the IESG did:
ignore the section. We would have happily supported any AD who wanted to review
or try the code by allowing access to our server.

> You probably also need to instruct the RFC
> Editor to remove it before publication?

[acm] OK
RFC Editor: This section is for the benefit of the Document Shepherd's form, 
and will be deleted prior to publication.

>>> I don't think this material from 8.4 made it into the Doc Shepherd's form,
which is one reason it's still hanging around...

> RFC8174 boilerplate. (It contains some text with a similar beginning.)
[acm] I think this is covered, section 1.1.

Ok, thanks.  I would like to know which tool(s) you used (and if free, 
even on a trial basis). Seemed to do a decent job.

> +    
no                                                             ++++
> +        to less traffic crossing ISP gateways in the future.
yes
> +     
yes
> -    Another approach comes from Section 24 of RFC 2544[RFC2544] and its
yes
> +    The path measured may be stateful based on many factors, and the
yes
> +
yes

                                                                  ^
> An apostrophe may be missing.
no
> Unpaired symbol: ')' seems to be missing
yes
> Possible typo: you repeated a word
yes
> Did you mean "in me", "in her", "in him", "in us", or "in them"?
no
> are closely connected and short).
no
> word is not a noun in standard English.
yes
> Consider using "Many".
alt solution, "different types of" 
> The usual collocation for "independently" is "of", not "from". Did you
yes
> or possibly some other part of speech.
yes
> Consider simply using "of" instead.
no
> e.g. 'a sentence', 'a university'.
yes
> If the text is a generality, 'of the' is not necessary.
yes
> >  200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420
yes
> >  200 Laurel Avenue South Middletown,, NJ 07748 USA Email: lencia@att
yes

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 May 2021 10:04:58 +0300

Hi Al,

> @@@@ Is the DOWNREF registry an action item for chairs or AD/Martin?

yes, another LC will unfortunately be needed. It's an action item for Martin.

> So, I don't want to emphasize the term "access" as you propose.

That's fine, too. When reading the document, I came away with the impression that it did want to focus on measuring access networks, because it actually says that in several places (e.g., the quote above.) If the intent is for this to be a general metric for IP paths, maybe review the places where the document talks about "access" to make sure they are not giving the wrong impression.

> referred to as the Internet access.

It's not only the intro, though. There is text talking about "access" throughout the document.

> [acm] With s/evaluations/metrics/ this WFM.

WFM

> identify cases where more testing is warranted, possibly with alternate

WFM

>> of the load adjustment algorithm is RECOMMENDED."

WFM

> [acm] IOW, when you subscribe to a 1 Gbps service, then your ISP, you, and possibly other parties want to assure that performance level is delivered. If you test and confirm the subscribed performa…

That context would be helpful to have in the document in some form, IMO.

> [acm] I think *host* is general-enough to include CPE that is the source or destination of test packets. Also, "globally routable" is part of an example.

I still wonder if removing "globally routable" would reduce confusion here, but OK.

> measurement feedback instead.

Maybe I should have said "complex" :-)

> CCA in TCP. Our scope is infrequent, diagnostic measurements.

Point taken.

>     for the method to declare congestion), the offered load rate is increased ...

WFM

>    for two consecutive feedback intervals. ...

WFM

> which is one reason it's still hanging around...

WFM

> [acm] I think this is covered, section 1.1.

WFM

> even on a trial basis). Seemed to do a decent job.

https://github.com/larseggert/ietf-reviewtool

Thanks,
Lars

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 May 2021 15:29:52 -0700

OK, I've had a look at this, and I don't see why this is a normative
reference at all!

The primary application of the metric and method of measurement
   described here is the same as in Section 2 of [RFC7497]
<https://datatracker.ietf.org/doc/html/rfc7497#section-2> where:

   o  The access portion of the network is the focus of this problem
      statement.  The user typically subscribes to a service with
      bidirectional access partly described by rates in bits per second.

How is this necessary to implement the draft?

Happy to be corrected on this!

[Also, appropriately ashamed to have missed it in my AD review]

Martni

On Tue, May 18, 2021 at 12:05 AM Lars Eggert <[email-masked]> wrote:

> > 1. The term "access" doesn't have a universally agreed definition
> regarding the portion of the network it covers, and that's partly because
> there are many architectures in use.
> >
> > 2. If we add access to the title or abstract, we are unnecessarily
> limiting the scope that we define later. We refer to section of RFC 7497
> where the figure includes the subscriber's device, multiple private
> networks, and various devices and gateways ending at a transit gateway.
> >
> That's fine, too. When reading the document, I came away with the
> impression that it did want to focus on measuring access networks, because
> it actually says that in several places (e.g., the quote above.) If the
> intent is for this to be a general metric for IP paths, maybe review the
> places where the document talks about "access" to make sure they are not
> giving the wrong impression.
>
> > [RG]+[acm] 1.  Internet access is no longer the bottleneck for many
> users, but subscribers expect network providers to honor contracted access
> performance.
> >
> > [acm] IOW, when you subscribe to a 1 Gbps service, then your ISP, you,
> and possibly other parties want to assure that performance level is
> delivered. If you test and confirm the subscribed performance level, then
> you can seek the location of the bottleneck elsewhere.
>
> > [acm] I think *host* is general-enough to include CPE that is the source
> or destination of test packets. Also, "globally routable" is part of an
> example.
>

---

From: "MORTON JR., AL" <[email-masked]>
Date: Wed, 19 May 2021 22:48:04 +0000

in-line,
Al

From: Martin Duke <[email-masked]>
Sent: Wednesday, May 19, 2021 6:30 PM
To: Lars Eggert <[email-masked]>
Cc: MORTON JR., AL <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Ian Swett <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: Lars Eggert's Discuss on draft-ietf-ippm-capacity-metric-method-10: (with DISCUSS and COMMENT)

OK, I've had a look at this, and I don't see why this is a normative reference at all!

   described here is the same as in Section 2 of [RFC7497]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7497*section-2__;Iw!!BhdT!xlfpewVBdgR2F4flazNgF3Ypkw-6ovu-odnTKamNrSa250ONVpnJdOv2Pnhu$> where:

How is this necessary to implement the draft?
[acm]
For Implementation, Not at all! But we use it to set the Scope and Applicability, which is a Normative section by its very nature, IMO. The Figure in RFC 7497 limits the applicability to a small number of administrative domains at the edge of the Internet, including what most people think of when they hear “Internet access”.

So, you can’t implement this RFC *and use it properly* without this reference.

Adding the reference to RFC 7497 was a big step in resolving Magnus’ comments. He didn’t want the Capacity test used end-to-end on the Internet, and RFC 7497 was the perfect solution.  But like all our framework RFCs, it’s Informational.

Happy to be corrected on this!
[acm]
I made my case, it’s your call.  We have a working version going for Lars’ comments, so it’s an easy fix.

[Also, appropriately ashamed to have missed it in my AD review]
[acm]
You didn’t miss it!  It wasn’t in the Scope/applicability section at that time!  This Ref was added for Magnus!

Martni

On Tue, May 18, 2021 at 12:05 AM Lars Eggert <[email-masked]<mailto:[email-masked]>> wrote:
Hi Al,

On 2021-5-17, at 21:00, MORTON JR., AL <[email-masked]<mailto:[email-masked]>> wrote:
> I also think that https://datatracker.ietf.org/doc/html/rfc7497<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7497__;!!BhdT!xlfpewVBdgR2F4flazNgF3Ypkw-6ovu-odnTKamNrSa250ONVpnJdPOyZrAO$> will figure

WFM

WFM

WFM

> Please see section 4 of https://datatracker.ietf.org/doc/html/rfc8337<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8337__;!!BhdT!xlfpewVBdgR2F4flazNgF3Ypkw-6ovu-odnTKamNrSa250ONVpnJdMQ2_xii$>

Point taken.

WFM

WFM

WFM

WFM

> even on a trial basis). Seemed to do a decent job.

https://github.com/larseggert/ietf-reviewtool<https://urldefense.com/v3/__https:/github.com/larseggert/ietf-reviewtool__;!!BhdT!xlfpewVBdgR2F4flazNgF3Ypkw-6ovu-odnTKamNrSa250ONVpnJdGUm8Z7Q$>

Thanks,
Lars

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 May 2021 16:17:16 -0700

Got it. According to RFC 8067, the IESG can just waive it when the AD
review misses it rather than go through another last call. I'll open that
subject at tomorrow's telechat -- unless the smart people in IPPM think
that changes warrant a new IETF Last Call in their own right.

On Wed, May 19, 2021 at 3:48 PM MORTON JR., AL <[email-masked]> wrote:

> in-line,
>
> Al
>
>
>
> *From:* Martin Duke <[email-masked]>
> *Sent:* Wednesday, May 19, 2021 6:30 PM
> *To:* Lars Eggert <[email-masked]>
> *Cc:* MORTON JR., AL <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; Ian Swett
> <[email-masked]>; The IESG <[email-masked]>; [email-masked]
> *Subject:* Re: Lars Eggert's Discuss on
> draft-ietf-ippm-capacity-metric-method-10: (with DISCUSS and COMMENT)
>
>
>
>    described here is the same as in Section 2 of [RFC7497] <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7497*section-2__;Iw!!BhdT!xlfpewVBdgR2F4flazNgF3Ypkw-6ovu-odnTKamNrSa250ONVpnJdOv2Pnhu$> where:
>
>
>
> *[acm] *
> *For Implementation, Not at all! But we use it to set the Scope and
> Applicability, which is a Normative section by its very nature, IMO. The
> Figure in RFC 7497 limits the applicability to a small number of
> administrative domains at the edge of the Internet, including what most
> people think of when they hear “Internet access”.*
>
>
>
> *So, you can’t implement this RFC *and use it properly* without this
> reference.*
>
>
>
> *Adding the reference to RFC 7497 was a big step in resolving Magnus’
> comments. He didn’t want the Capacity test used end-to-end on the Internet,
> and RFC 7497 was the perfect solution.  But like all our framework RFCs,
> it’s Informational.*
>
>
>
> *[acm] *
> *I made my case, it’s your call.  We have a working version going for
> Lars’ comments, so it’s an easy fix.*
>
>
>
> *[acm] *
> *You didn’t miss it!  It wasn’t in the Scope/applicability section at that
> time!  This Ref was added for Magnus!*
>
>
>
> Martni
>
>
>
> > I also think that https://datatracker.ietf.org/doc/html/rfc7497
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7497__;!!BhdT!xlfpewVBdgR2F4flazNgF3Ypkw-6ovu-odnTKamNrSa250ONVpnJdPOyZrAO$>
> will figure
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8337__;!!BhdT!xlfpewVBdgR2F4flazNgF3Ypkw-6ovu-odnTKamNrSa250ONVpnJdMQ2_xii$>
> <https://urldefense.com/v3/__https:/github.com/larseggert/ietf-reviewtool__;!!BhdT!xlfpewVBdgR2F4flazNgF3Ypkw-6ovu-odnTKamNrSa250ONVpnJdGUm8Z7Q$>
>
> Thanks,
> Lars
>
>

---

From: Martin Duke <[email-masked]>
Date: Thu, 20 May 2021 12:03:31 -0700

OK, we waived the downref.

If 7967 is going to be a perennial problem, I don't see that it meets any
of the downref criteria in 3967, and I would encourage the group to
consider updating its status to proposed standard.

On Wed, May 19, 2021 at 4:17 PM Martin Duke <[email-masked]> wrote:

>> [email-masked]; [email-masked]; Ian
>> Swett <[email-masked]>; The IESG <[email-masked]>; [email-masked]
>> *You didn’t miss it!  It wasn’t in the Scope/applicability section at
>> that time!  This Ref was added for Magnus!*
>>
>>
>>
>> Martni
>>
>>
>>
>> > [acm] I think *host* is general-enough to include CPE that is the
>> source or destination of test packets. Also, "globally routable" is part of
>> an example.
>>

---

From: Lars Eggert <[email-masked]>
Date: Fri, 21 May 2021 10:15:10 +0300

> OK, we waived the downref.

And I cleared my related DISCUSS.

Thanks,
Lars

---

From: "MORTON JR., AL" <[email-masked]>
Date: Sat, 29 May 2021 21:15:38 +0000

Hi Lars,

I'll trim this reply down to the essentials.

Al

> From: Lars Eggert <[email-masked]>
> Sent: Tuesday, May 18, 2021 3:05 AM
> To: MORTON JR., AL <[email-masked]>
...
...
> yes, another LC will unfortunately be needed. It's an action item for
[acm] 
Martin obtained a waiver for the LC; this DOWNREF didn't appear in the memo
until we addressed Magnus' comments. We're good here.

> It's not only the intro, though. There is text talking about "access"
[acm] 
I have substituted more descriptive terms where possible. Note that we 
use "Internet access" to describe a service, and that "on-demand access"
is now clarified as "on-demand communications access". The later clarification
convinced me to avoid pairing terms like "access" and "capacity" in the title,
where access capacity might be misconstrued as a number of users, or sessions,
or something else we don't intend.

...
> That context would be helpful to have in the document in some form, IMO.
[acm] 
Ok, added to the intro.

...
> Maybe I should have said "complex" :-)
[acm] 
That's closer, although it's 20 lines of pseudocode... wondering how that 
compares to CUBIC or BBR (and not stopping to look).
...

> >>
> >> -----------------------------------------------------------------------
> ---
> >> -----
[acm] 
Thanks, I had tried the idcomments tool, once. I must not have been won-over.
I'll try yours at my next opportunity (which is probably already in my to-do
list).

Thanks again for your review!  We have Zahed's comments now and there will be a 
revised draft shortly.

Al