In the following places we may change the suggested inputs from the review:
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.
(Not include the discovery part)
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.
Include some of the changes in https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-enghardt-panrg-path-properties-03-rev%20Med.pdf
In the following places we may change the suggested inputs from the review:
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.
(Not include the discovery part)
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.