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

[<[e-mail]>]

Hi Theresa,

Thank you. Please see inline.

Cheers,
Med

De : Panrg [mailto:[e-mail]] De la part de Theresa Enghardt
Envoyé : jeudi 5 décembre 2019 17:30
À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
Objet : [PANRG] Response to review (Re: Fwd: New Version Notification for draft-enghardt-panrg-path-properties-03.txt)

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]<mailto:[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.

[Med] That is OK with me as far the example is consistent with the previous text. An SF can be a standalone physical device or a provided as a virtual element (RFC7665, Section 1.4).

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.

[Med] OK.

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

[Med] Sure. A path (no matter how it is known to a host) should not be seen as static and frozen. I do see a value in capturing that characteristic in the definition.

, but does not attempt to answer the question on how we can discover such path properties and paths.

[Med] Agree.

 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.

[Med] In the same way that we don’t elaborate on how a property is assessed/observed, we won’t elaborate on a how a node/path/sub-path are known to the host in this draft.

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.

[Med] Having it in the use case section would be OK.

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?

[Med] The term can be used in the use case section to illustrate, e.g., how a discovered node can be included/excluded from the actual path.

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.

[Med] OK, thanks.

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.

[Med] The point is to have something concrete as this section is about “Examples”.

Best,
Theresa