Address comment C 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.

<...>

C. I can see why it is useful to indicate that a secondary path has the
same end points as the primary path...

        4.  An empty 'route-object-include-exclude' list for the
            secondary (forward) path indicates that the secondary
            path has the same endpoints as the primary path.

... but don't you need the ability to specify some inclusion and
exclusion along the secondary path?

• Proposed text updates

[italobusi]

I think there was some mistake. The rule, as written at the beginning, seems to be applicable also to the secondary paths of e2e Tunnels

        4.  An empty 'route-object-include-exclude' list for the
            secondary (forward) path indicates that the route objects to be included or excluded
            for the secondary path are the same as the route objects to be included or excluded
            for the primary path

The fact that, in case of a TE Tunnel Segment, the endpoints of the secondary path are the same as the endpoints of the primary path is just a consequence of defining the endpoints of a path segment in the 'route-object-include-exclude' list and the elements are the same of the primary path

[tsaad-dev]

FROM:

        4.  An empty 'route-object-include-exclude' list for the
            secondary (forward) path indicates that the secondary
            path has the same endpoints as the primary path.

TO:

        4.  An empty 'route-object-include-exclude' list for the
            secondary (forward) path of a TE Tunnel segment indicates that the secondary
            path has the same endpoints as the primary path.

[tsaad-dev]

addressed