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

["Brian Trammell (IETF)" <[e-mail]>]

hi Spencer,

Yep, that's better. Will push it to working copy but hold for auth48.

Thanks, cheers,

Brian

> On 11 Oct 2021, at 18:09, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> 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