Hi Christian,
On Tue, Oct 19, 2021 at 2:54 AM Christian Amsüss <christ...@amsuess.com>
wrote:
> Hello Richard,
>
> On Mon, Oct 18, 2021 at 03:43:50PM -0400, Y. Richard Yang wrote:
> > Good comment. The document gives the high-level grammar (1 line) at the
> > beginning of Sec. 2.2.
> > It looks that your suggestion is the write out the complete grammar
> upfront:
>
> I was not so much looking for the details of the terms "where <stat>
> MUST be one of the following" was fine) but for
>
> a) naming the formal language this is in. Reading, I've guessed that the
> square brackets mean "optional" because I've seen that in DOS-time
> documentation, and it looks formal, but does not declare a language.
>
A formal language that could be used here and is common in RFCs would
> be ABNF.
>
>
I see. See below, as we can address them together.
> b) the tying in of the output -- the the term "metric-identifier" is not
> used anywhere else, and RFC7285 uses a CostMetric type in the
> cost-metric field; I'd appreciate if these identifiers were somehow
> linked.
>
This would be trivial had ALTO used CDDL to describe its JSON, as
> then there could be a line like `cost-metric //= metric-identifier`;
> maybe the `object { ... }` notation has something similar?
>
> The object notation is higher granularity and hence cannot handle strings
structure.
> RFC7285 generally does without constructing string identifier, so
> there is no ABNF in there.
>
> Correct.
> If you go with the suggested colon structuring and have text for that,
> possibly there the optionality and string concatenation be described
> in ABNF (or just in words with an example), and the need for a formal
> language would go away here.
>
>
Good comment. How about the following:
Old Sec. 2.2
"Hence, each performance metric's identifier
should indicate the statistic (i.e., an aggregation operation), to
become
<metric-identifier> ::= <metric-base-identifier> [ '-' <stat> ]
where <stat> MUST be one of the following:
"
=>
"Hence, this document extends the general US-ASCII alphanumeric cost metric
strings (formally specified as the CostMetric type in Section 10.6 of
[RFC7285]) as follows: A cost metric string (denoted <cost-metric>)
consists of a base metric identifier string (denoted
<metric-base-identifier>) followed by an optional statistics string
(denoted <stat>), connected by the ASCII character colon (':', U+003A), if
the statistics field exists. Examples of cost metric strings include
"delay-ow", "delay-ow:min", "delay-ow:p99".
> "... Note that some systems use quantile, which is in the range [0, 1].
> > This document uses percentile to make the identifier easier to read. When
> > there is a more common form for a given percentile, it is RECOMMENDED
> that
> > the common form being used; that is, instead of p0, use min; instead of
> > p50, use median; instead of p100, use max".
>
> Fine with me.
>
>
Great.
> > > * Allowing decimals into the cost metric identifier introduces a dot
> which
> > > is reserved as per RFC7285 Section 10.6.
> >
> > Yes. Correct. From the grammar above, we made sure that we would not
> > introduce a dot. We can add a sentence to point out that when choosing
> the
> > base, we should follow this. Should we do this?
>
> I think it'd be easiest (with the grammar or without) to to introduce
> the number as a nonnegative integer. (That'd allow dropping mentions of
> the minus and exp components).
>
> Agree.
> > > A way out could be to formalize this structure and register the
> > > metric-base-identifiers for use with and without a stat parameter
> > > following the colon (instead of the dash).
> >
> > So the suggestion is that ":" as the consistent internal structure
> > separator. This is quite reasonable.
>
> Just beware that this is formally an update to the registry; not sure
> whether that incurs an "updates" to 7285.
>
>
No. This will not update 7285. Sec. 10.6 of RFC7285 requires registration
and we will do so.
> > > A few words on which statistic can be used with which metric could
> > > also help with bw-maxres. (What does bw-maxres-p50 mean, is it
> > > meaningful at all?)
> >
> > Mathematically, any percentile of a set of a single value is the value
> > itself. But it is indeed a good idea to clarify it. We will add a
> sentence
> > at the end of 2.2
> >
> > => Note that although one can use generic statistics (i.e., any
> percentile
> > in [0, 100]) and multiple specifications may give the same value, it
> helps
> > to choose the more intuitive and robust definition. For example, when the
> > set is expected to be a single value. The max operator is more robust and
> > hence recommended.
>
> That sounds more confusing to me (the max operator ... so I should use
> bw-maxres-max?); maybe (if correct) something like
>
> | Note that unlike the other metrics, maxres is a single value and not
> | sampled over time. Thus, it MUST NOT be specialized with a stat
> | indicator, but is to be used in the base form.
>
> Sounds good to me. We will use your wording.
> > > * "Content-Length: TBA": Does this add value to the examples?
> >
> > We will add the final exact value when publishing, as it is part of HTTP
> > header.
>
> Sure it is part of the HTTP header, but so are many other headers
> (Accept-Content-Encoding, User-Agent, what so not). Accept and
> Content-Type add to the understanding, Content-Length will IMO be
> ignored by all readers anyway.
>
>
OK. We will add the final value now.
> > It is an example to illustrate both ipv4 and ipv6. If we do ipv4->ip4 and
> > ipv6-ipv6, we will need two examples, and it takes more space.
>
> Does it need examples of all of them? These are not unit tests, they are
> illustrative.
>
> Indeed. They are illustrative and we can drop the mix use to avoid
confusion.
> > > * "the -<percentile> component": "any 'stat' component"?
> >
> > Not sure what this is? Any more specific locator?
>
> 3.1.3
>
> > Very good comment! We have made the changes. The newer version fixed
> this
> > issue.
> > Please see -18 which is just loaded today.
>
> Didn't see that at first ... something was changed in the uplaod process
> and now there's no HTML version any more?
>
>
We will upload a newer version to address all issues soon and then I will
debug to make sure that is an HTML version.
Thank you so much!
Richard
> BR
> c
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater
> powers.
> -- Bene Gesserit axiom
>
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
