Re: [Teas] WG Last Call: draft-ietf-teas-actn-vn-yang-19 editorial

[tom petch <[e-mail]>]

Some more straightforward comments on -21 for you to consider.

'referred' appears in several places.  This looks right in its first appearance in s.2.1 and in s.8 but elsewhere  I suspect that 'referenced' is intended.

s.3.1
the first line of the diagram is indented one character
/and update/and updates/
{which has been bugging me for years)

s.6
container underlay
/Segement/Segment/

vn-id
unique but within what scope?  I see users get this sort of thing wrong, usually underestimating the scope and then getting duplication and so confusion.  I think that unique should always have a some indication of scope

Appendix A
/this YANG model rely/this YANG module relies/
[[RFC8776] define/[RFC8776] defines/

HTH

Tom Petch
________________________________________
From: Teas <[e-mail]> on behalf of tom petch <[e-mail]>
Sent: 25 October 2023 12:00
To: Dhruv Dhody; Italo Busi
Cc: [e-mail]; Sergio Belotti (Nokia); Vishnu Pavan Beeram; TEAS WG; TEAS WG Chairs
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-actn-vn-yang-19

From: Dhruv Dhody <[e-mail]>
Sent: 23 October 2023 06:41

Based on the example of node-id that I have seen in the wild (for instance here in ODL - https://docs.opendaylight.org/projects/bgpcep/en/latest/bgp/bgp-user-guide-topology-provider.html), the use of dotted-quad string for URI is common in implementations.

But if I look at the ABNF of URI at https://datatracker.ietf.org/doc/html/rfc3986#appendix-A, that is incorrect. And YANG tools are unlikely to flag it.

I am happy to make the change that Med suggests, I am also open to any guidance from netmod/YANGdoctors if they have it.

<tp>

Meanwhile I have looked at -21 and think that it is in worse shape, with more errors than-19.

It is TE where the ants' nest of ID and RFC gets higher by the day and ever more obtuse.  I just spent an hour trying to identify the syntax of the types  used in s.7.2 and with several can see that they are wrong but with others it is just too complicated to tell.

As I said before, I assume that node-id and network-id come from RFC8345 and so must be type uri; some now are, some are not - needs fixing.

With the example being JSON it is much harder to see what is happening and very time consuming to track down the te types.  Some are now uri which I do not think that they should be, or at least need to be and making them so I think confusing.  Thus I believe topology-id is null or a restricted string not a URI.  The examples make it look identical to those that must be a URI; this may or not be valid but I think confusing.

I have some editorial comments which I send separately.

Tom Petch
--

And to answer Tom's original question, we need to include both node-id and "ietf-te-topology:te-node-id", and I tried to simplify things by using the same value for both and thus leading to the confusion that you had...

--

@ Med - Maybe I can sit with you during the IETF week/hackathon to sort out the yang validation via Yangson? I did a test with yanglint earlier...

Thanks!
Dhruv






On Mon, Oct 23, 2023 at 4:11 AM Italo Busi <Italo.Busi=[e-mail]<mailto:[e-mail]>> wrote:
Tom, Med,