[PANRG] Response to review (Re: Fwd: New Version Notification for draft-enghardt-panrg-path-properties-03.txt)

[Theresa Enghardt <[e-mail]>]

Dear Med,

Thank you for supporting adoption and for the additional inputs.

Having discussed the inputs with my co-author, please find some initial
responses below:

On 26.11.19 16:52, [e-mail] wrote:
> […]
>
> FWIW, you may find some additional inputs at:
>
> ·         pdf:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-enghardt-panrg-path-properties-03-rev%20Med.pdf
>
>
> ·         doc:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-enghardt-panrg-path-properties-03-rev%20Med.doc
>
First, thanks for all the editorial comments, we think they help improve
clarity, especially in some of the existing definitions.

Then, we have some comments and questions about the possibility of
adding more definitions or substantially extending our existing definitions.

In the "Node" definition, we would like to highlight that a node can be
physical or virtual, so we decided we wanted to give examples for both -
so we'll put in "e.g., a physical machine or a service function" (and
not virtual machine), because the service function is an example for a
virtual node, so we'll have the machine be a physical one.

Towards the end of the "Path" definition, there's a sentence on path
visibility. We would like to make sure that the visibility aspect is
clear in our definitions, but we are not sure yet whether adding this
particular sentence is the best way to do it, as we already have a
sentence on visibility right before. We'll consider how to phrase and
possibly consolidate our definition in the next revision.

Still as part of the "Path" definition, about the sentence with the
visible paths being volatile and multiple paths being available: We are
not sure whether this is still part of the path definition or whether
this is already talking about how a host handles or discovers paths.
Here we would like to be careful about the scope of our draft: The draft
provides a terminology for path properties and paths, but does not
attempt to answer the question on how we can discover such path
properties and paths. Essentially, we are addressing question 1 in the
Questions Draft, but not question 2, which talks about discovering path
properties. Therefore, we would like to avoid talking about how to
discover paths, path elements, or path properties in this draft if we
can. Perhaps the content on discovering paths or nodes can be part of a
different "Discovery Draft" to be written in PANRG. Or maybe to some
extent they can be part of the Use cases section, as we already talk
about invoking additional path elements to become part of the path.

The above similarly applies to the "Discovered Node" - If you think we
require this definition to be part of our base terminology to talk about
paths and path properties, could you explain why, please?

Also, if you or anyone else in the Research Group has any thoughts on
the scope of this draft VS the discovery of paths and path properties,
we'd love to hear them.

The definitions of Reverse path and Symmetric path seem useful to us as
part of a base terminology for path properties, so we'll include them.

Thank you for the input on the "Use cases" section. We are going to
revise this section based on input we got at IETF 106, and we will
consider your feedback as well when doing so. As we revise our use cases
section, we will consider whether to put any reference to them into the
abstract or not.

For the definition of the "Transport Protocols available" property,
again, we are not sure we want to go into detail about how to discover
or cache this property, so we would opt for less detail here.

Best,
Theresa