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

[[e-mail]]

Hi Italo, 

As per STD66, the scheme part is required. The use of the literals is allowed in the host part as per Section 3.2.2 of STD66.

As per the values used in examples, here is what draft-ietf-netmod-rfc8407bis says: 

==
   For some types (IP addresses, domain names, etc.), the IETF has
   reserved values for documentation use.  Authors SHOULD use these
   reserved values in the usage examples if these types are used.
   Examples of reserved values are listed below:

   *  IPv4 and IPv6 addresses/prefixes reserved for documentation are
      defined in [RFC5737] and [RFC3849].

   *  The Enterprise Number 32473 reserved for documentation use is
      defined in [RFC5612].

   *  Autonomous System Numbers (ASNs) reserved for documentation use
      are defined in [RFC5398].

   *  Reserved domain names for documentation are defined in [RFC2606].

   URI examples SHOULD be prefixed with "example:".
==

Cheers,
Med

> -----Message d'origine-----
> De : Italo Busi <[e-mail]>
> Envoyé : lundi 23 octobre 2023 00:41
> À : tom petch <[e-mail]>; BOUCADAIR Mohamed INNOV/NET
> <[e-mail]>; Sergio Belotti (Nokia)
> <[e-mail]>; Vishnu Pavan Beeram
> <[e-mail]>; TEAS WG <[e-mail]>
> Cc : TEAS WG Chairs <[e-mail]>; [e-mail]
> Objet : RE: [Teas] WG Last Call: draft-ietf-teas-actn-vn-yang-19
> 
> 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]>
> > Sent: giovedì 19 ottobre 2023 12:15
> > To: [e-mail]; Sergio Belotti (Nokia)
> > <[e-mail]>; Vishnu Pavan Beeram
> > <[e-mail]>; TEAS WG <[e-mail]>
> > Cc: TEAS WG Chairs <[e-mail]>; [e-mail]
> > Subject: Re: [Teas] WG Last Call: draft-ietf-teas-actn-vn-yang-19
> >
> > From: [e-mail]
> > <[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]> Envoyé : mercredi 18 octobre
> > > 2023 10:29 À : BOUCADAIR Mohamed INNOV/NET
> > > <[e-mail]>; Sergio Belotti (Nokia)
> > > <[e-mail]>; Vishnu Pavan Beeram
> > > <[e-mail]>; TEAS WG <[e-mail]> Cc : TEAS WG
> Chairs
> > > <[e-mail]>; [e-mail] Objet : Re: [Teas] WG
> > > Last Call: draft-ietf-teas-actn-vn-yang-19
> > >
> > > From: [e-mail]
> > <[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%
> 2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbffd5e04e37947f2099
> f08dbd35005a6%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63833611286
> 7459526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7sU88PIy7uf56scP5O%
> 2FgiV%2BrDrdOB6b1mS6rvMlmhV4%3D&reserved=0.
> > > rfc-
> > >
> > editor.org%2Ferrata%2Feid6900&data=05%7C01%7Cmohamed.boucadair%
> > 40orang
> > >
> > 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]> De la part de tom petch Envoyé
> :
> > > > lundi 16 octobre 2023 13:11 À : Sergio Belotti (Nokia)
> > > > <[e-mail]>; Vishnu Pavan Beeram
> > > > <[e-mail]>; TEAS WG <[e-mail]> Cc : TEAS WG
> > Chairs
> > > > <[e-mail]>; [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]> on behalf of Sergio Belotti
> > > (Nokia)
> > > > <[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]> On Behalf Of Vishnu Pavan
> > > > Beeram
> > > > Sent: Tuesday, September 12, 2023 2:19 PM
> > > > To: TEAS WG <[e-mail]>
> > > > Cc: TEAS WG Chairs <[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
> 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%7Cbffd5e04e37947f209
> >
> 9f08dbd35005a6%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383361128
> >
> 67459526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1J8bsTyF5GduexKCFt
> > 8qz10PQKembxCebfBNxDKCjCs%3D&reserved=0
> > > >
> > > %2F&data=05%7C01%7Cmohamed.boucadair%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%2Fdoc%2Fdraft-ietf-teas-actn-vn-
> > > >
> > >
> > yang%2F&data=05%7C01%7Cmohamed.boucadair%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]
> > > >
> > >
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%
> > >
> > 2F&data=05%7C01%7Cmohamed.boucadair%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%2Fmailman%2Flistinfo%2Fteas&data=05%7C01%7Cmohamed.bouc
> > adair%
> > > >
> > >
> > 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.
> >
> >

____________________________________________________________________________________________________________
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.