Re: [PANRG] I-D Action: draft-irtf-panrg-questions-10.txt

[Spencer Dawkins at IETF <[e-mail]>]

Brian, I have a ridiculously small suggestion, which you could sit on until
AUTH48, if it seems appropriate. It really is that small.

On Mon, Oct 11, 2021 at 8:34 AM <[e-mail]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Path Aware Networking RG RG of the IRTF.
>
>         Title           : Current Open Questions in Path Aware Networking
>         Author          : Brian Trammell
>         Filename        : draft-irtf-panrg-questions-10.txt
>         Pages           : 10
>         Date            : 2021-10-11
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-irtf-panrg-questions-10.html


While looking over -10 (as shepherd), I noticed that the subsections in
section 2 follow this structure:

   - Brief subsection title that gestures toward a question
   - Exposition about the question
   - The question, expressed as a complete sentence.

It's not easy to spot the question, expressed as a complete sentence,
unless you know what you're looking for. I'm only realizing this now,
because I've seen versions of these questions in Powerpoint so many times,
so I know what to look for (at the bottom of each slide).

I wonder if this would be clearer, as

   - Brief subsection title that gestures toward a question
   - The question, expressed as a complete sentence.
   - Exposition about the question

So, instead of

2.1. A Vocabulary of Path Properties

In order for information about paths to be exposed to an endpoint, and for
the endpoint to make use of that information, it is necessary to define a
common vocabulary for paths through an internetwork, and properties of
those paths. The elements of this vocabulary could include terminology for
components of a path and properties defined for these components, for the
entire path, or for subpaths of a path. These properties may be relatively
static, such as the presence of a given node or service function on the
path; as well as relatively dynamic, such as the current values of metrics
such as loss and latency.


This vocabulary must be defined carefully, as its design will have impacts
on the expressiveness of a given path-aware internetworking architecture.
This expressiveness also exhibits tradeoffs. For example, a system that
exposes node-level information for the topology through each network would
maximize information about the individual components of the path at the
endpoints, at the expense of making internal network topology universally
public, which may be in conflict with the business goals of each network's
operator. Furthermore, properties related to individual components of the
path may change frequently and may quickly become outdated. However,
aggregating the properties of individual components to distill end-to-end
properties for the entire path is not trivial.


The first question: how are paths and path properties defined and
represented?


Each section would look like this:

2.1. A Vocabulary of Path Properties

The first question: how are paths and path properties defined and
represented?

In order for information about paths to be exposed to an endpoint, and for
the endpoint to make use of that information, it is necessary to define a
common vocabulary for paths through an internetwork, and properties of
those paths. The elements of this vocabulary could include terminology for
components of a path and properties defined for these components, for the
entire path, or for subpaths of a path. These properties may be relatively
static, such as the presence of a given node or service function on the
path; as well as relatively dynamic, such as the current values of metrics
such as loss and latency.


This vocabulary must be defined carefully, as its design will have impacts
on the expressiveness of a given path-aware internetworking architecture.
This expressiveness also exhibits tradeoffs. For example, a system that
exposes node-level information for the topology through each network would
maximize information about the individual components of the path at the
endpoints, at the expense of making internal network topology universally
public, which may be in conflict with the business goals of each network's
operator. Furthermore, properties related to individual components of the
path may change frequently and may quickly become outdated. However,
aggregating the properties of individual components to distill end-to-end
properties for the entire path is not trivial.


Does this seem helpful?

Best,

Spencer