Address comment B on section 5.1.1 of draft-ietf-teas-yang-te-38

[italobusi]

It seems to me that the description of the route-object-include-exclude list is
complex. Are you sure you are not overloading the meaning? That is, the
interpretation of an empty list might be less convoluted if it was conveyed by
distinct objects.

There is also some confusion in my mind about the details.

<...>

B. I don't understand the following...

        2.  An empty 'route-object-include-exclude' list for the
            primary path of a TE Tunnel Segment indicates that no
            primary LSP is required for that TE Tunnel.

What does it mean to have no primary path? Also, should an additional
"Segment" be added to the end of the paragraph?

Further, the previous point says:

        1.  An empty 'route-object-include-exclude' list for the
            primary path of an end-to-end TE Tunnel indicates that
            there are no route objects to be included or excluded in
            the path computation.

...and it seems to me that a segment could be the entire e2e tunnel.

• (Pavan): Provide some text proposal

[tsaad-dev]

Add example at the end of the document and reference in item 2 of section 5.1

[italobusi]

Example added in PR #316

From the example, I wonder whether we can replace "TE Tunnel Segment" with "TE Tunnel Transit Segment" (i.e., a TE tunnel with no source and no destination) since this is the only case where the primary path may not be setup

[tsaad-dev]

Fix Figure to not include inter-domain links. Domain will be back-to-back.

[italobusi]

In the -39 version, there are some 'path-scope' in the configuration data which should be removed

See PR #318

Can you fix it before IETF 124 cut-off?