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

[tom petch <[e-mail]>]

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,

I have few comments about this discussion

The node-id is mandatory since it is the key for the node list as defined in RFC8345

The te-node-id is also mandatory when the te presence container is present under the node as specified in the must statement in RFC8795

In past discussions I have been told that a dotted-quad string is a valid URI so the node-id can be set equal to the te-node-id but it does not have to (that's why in some case node-id is set to 'D1' and in other cases is set as a dotted-quad values equal to te-node-id)

However, I have not been able to find any definitive answer (e.g., an on-line validation tool) that confirms or contradicts that a dotted-quad string is a valid URI: do you know some reference?

Last comment: in other documents, I have got the comment that we need to use values in the reserved range defined in RFC5737 also for the dotted-quad identifiers used in the examples

My 2 cents

Italo

> -----Original Message-----
> From: tom petch <[e-mail]<mailto:[e-mail]>>
> Sent: giovedì 19 ottobre 2023 12:15
> To: [e-mail]<mailto:[e-mail]>; Sergio Belotti (Nokia)
> <[e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram
> <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
> Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Subject: Re: [Teas] WG Last Call: draft-ietf-teas-actn-vn-yang-19
>
> From: [e-mail]<mailto:[e-mail]>
> <[e-mail]<mailto:[e-mail]>>
> Sent: 18 October 2023 09:47
>
> Hi Tom,
>
> > But is node-id the correct leaf?
>
> It is correct as the parent is "ietf-network:networks". te-specific data nodes
> are prefixed with "ietf-te-topology" (e.g., "ietf-te-topology:te-node-id").
>
> <tp>
> I disagree.  'node-id' does not appear anywhere else in the I-D and 'te-node-
> id' does and the example used to contain 'te-node-id'  so while the YANG
> heirarchy may be correct for 'node-id', I suspect that authors have the
> wrong leaf and so the wrond YANG heirarchy.
>
> Tools will not detect such an error if error it is.
>
> Tom Petch
>
>
> Anyway, I recommend the authors to run yangson against all the examples
> (in addition to fixing all the uri entries as per the erratum I shared earlier).
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : tom petch <[e-mail]<mailto:[e-mail]>>
> > Envoyé : mercredi 18 octobre 2023 10:29 À : BOUCADAIR Mohamed
> > INNOV/NET <[e-mail]<mailto:[e-mail]>>; Sergio Belotti (Nokia)
> > <[e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram
> > <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>> Cc : TEAS WG Chairs
> > <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> Objet : Re: [Teas] WG
> > Last Call: draft-ietf-teas-actn-vn-yang-19
> >
> > From: [e-mail]<mailto:[e-mail]>
> <[e-mail]<mailto:[e-mail]>>
> > Sent: 17 October 2023 12:45
> >
> > Hi Tom, all,
> >
> > >             "node-id": "192.0.2.1",
> >
> > Changing to "example:192.0.2.1" would make it a valid URI.
> >
> > The same fix applies to many similar data nodes in Section 7.
> >
> > BTW, please note that even the examples in RFC8345 with data nodes of
> > type uri are wrong (see for example
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > rfc-
> >
> editor.org<http://editor.org>%2Ferrata%2Feid6900&data=05%7C01%7Cmohamed.boucadair%
> 40orang
> >
> e.com<http://e.com>%7C6b4f6e40f41c4dcf214e08dbcfb453bf%7C90c7a20af34b40bfbc48b
> 9253b6
> >
> f5d20%7C0%7C0%7C638332145624887074%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4
> >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> C%7C%7
> >
> C&sdata=iCVk8eJKCSdtxNdAlsTZE4oLt3yH%2FhjocyofkCl1zDA%3D&reserved
> =0).
> >
> > <tp>
> >
> > But is node-id the correct leaf?
> >
> > A few years ago, the example had both node-id and te-node-id leaves,
> > the former with a value of 'D1', the latter with a value of '2.0.1.1'
> >
> > I note that everywhere else in the I-D there are references to te-
> > node-id and none to node-id.
> >
> > Tom Petch
> >
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Teas <[e-mail]<mailto:[e-mail]>> De la part de tom petch Envoyé :
> > > lundi 16 octobre 2023 13:11 À : Sergio Belotti (Nokia)
> > > <[e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram
> > > <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>> Cc : TEAS WG
> Chairs
> > > <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> Objet : Re: [Teas] WG
> > > Last Call: draft-ietf-teas-actn-vn-yang-19
> > >
> > > Picking a related e-mail to tack my comment onto
> > >
> > > From: Teas <[e-mail]<mailto:[e-mail]>> on behalf of Sergio Belotti
> > (Nokia)
> > > <[e-mail]<mailto:[e-mail]>>
> > > Sent: 16 October 2023 10:00
> > >
> > > Hi Pavan, WG,
> > >
> > > I support this work (as contributor) and think that it is  ready to
> > > move forward as soon as Adrian's comments have been successfully
> > > addressed.
> > >
> > > <tp>
> > > I am confused.  Looking at the example in e.g. 7.2 I see
> > >
> > > {
> > >   "ietf-network:networks": {
> > >     "network": [
> > >       {
> > > ....
> > >         },
> > >         "node": [
> > >           {
> > >             "node-id": "192.0.2.1",
> > > If this is the node-id of RFC8345 then that is of type node-id which
> > > is a URI.  I am not used to seeing URI in this format.
> > >
> > > If I search the rest of the I-D, I do not see node-id.  Rather s.3.1
> > > has te-node-id which is a different YANG type.
> > >
> > > This confuses me.
> > >
> > > I do have some more, more editorial, comments but am stuck on this
> > > one.
> > >
> > > Tom Petch
> > >
> > >
> > > Thanks
> > > Sergio (as contributor)
> > >
> > >
> > > From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of Vishnu Pavan Beeram
> > > Sent: Tuesday, September 12, 2023 2:19 PM
> > > To: TEAS WG <[e-mail]<mailto:[e-mail]>>
> > > Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
> > > Subject: [Teas] WG Last Call: draft-ietf-teas-actn-vn-yang-19
> > >
> > >
> > > CAUTION: This is an external email. Please be very careful when
> > > clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for
> > > additional information.
> > >
> > >
> > > All,
> > >
> > > This starts a two-week working group last call on
> > >
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > >
> > %2F&data=05%7C01%7Cmohamed.boucadair%40orange.com<http://40orange.com>%7C6b4f6e4
> 0f41c4dcf21
> > >
> >
> 4e08dbcfb453bf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> 83321456
> > >
> >
> 24887074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luMzIiL
> > >
> >
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Uidlg8ivXIt
> 48ATDJj
> > > lcbpOEgrqXu4iV9cTA%2FYMq8jY%3D&reserved=0
> > > tracker.ietf.org<http://tracker.ietf.org>%2Fdoc%2Fdraft-ietf-teas-actn-vn-
> > >
> >
> yang%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com<http://40orange.com>%7Cd37cf
> deb47e743
> > >
> >
> 9fcc4b08dbce3893db%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0
> %7C638330
> > >
> >
> 514615737399%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luM
> > >
> >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=isc5aJp9
> gX5UlZ
> > > CweI%2BYW3B4k5YTFHvzXItnxfREEB4%3D&reserved=0
> > >
> > > The working group last call ends on September 26th, 2023.
> > > Please send your comments to the working group mailing list.
> > >
> > > Positive comments, e.g., "I've reviewed this document and believe it
> > > is ready for publication", are welcome!
> > > This is useful and important, even from authors.
> > >
> > > Note: IPR has been disclosed on this document
> > >
> > > Thank you,
> > > Pavan, Lou and Oscar
> > >
> > > _______________________________________________
> > > Teas mailing list
> > > [e-mail]<mailto:[e-mail]>
> > >
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%
> >
> 2F&data=05%7C01%7Cmohamed.boucadair%40orange.com<http://40orange.com>%7C6b4f6e40f4
> 1c4dcf214
> >
> e08dbcfb453bf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> 33214562
> >
> 4887074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLC
> >
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EyREJi%2Be
> wo3aUl8ym
> > 6kdDAVy%2BsHNgH4Glm2qgnFOnEY%3D&reserved=0.
> > >
> >
> ietf.org<http://ietf.org>%2Fmailman%2Flistinfo%2Fteas&data=05%7C01%7Cmohamed.bouc
> adair%
> > >
> >
> 40orange.com<http://40orange.com>%7Cd37cfdeb47e7439fcc4b08dbce3893db%7C90c7a20af34b4
> 0bfbc48
> > >
> >
> b9253b6f5d20%7C0%7C0%7C638330514615737399%7CUnknown%7CTWFp
> bGZsb3d8eyJW
> > >
> >
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 3000%
> > >
> >
> 7C%7C%7C&sdata=9YMjzkWS1RrsNOCwO9ZkH%2BFVgoP65xUM0lkE4%2Bb
> VzuU%3D&rese
> > > rved=0
> >
> ________________________________________________________________
> ______
> > ______________________________________
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message a ete
> > altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> > delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> > been modified, changed or falsified.
> > Thank you.
>
> ________________________________________________________________
> ____________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>

_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas