Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[[e-mail]]

Hi Jürgen,

I agree this is marginal, but the proposed change is mainly to ensure some consistency and to some extend avoid collision with other SDOs. In the meantime, the initial reco is not technically justified :-) 

Please note that the initial reco is not always followed in practice: for example, we do have in the registry:

* ietf-mud, while mud is available 
* ietf-acldns while acldns whould be OK
* ietf-syslog while syslog would be 
* packet-fields while pf would be OK as per the 8487
* sain-interface while sain-if would work
...

Almost the majority of the IANA-maintained modules are prefixed with 'iana-".

Cheers,
Med

> -----Message d'origine-----
> De : Jürgen Schönwälder <[e-mail]>
> Envoyé : vendredi 15 mars 2024 15:24
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]
> Objet : Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-
> ietf-netmod-rfc8407bis
> 
> I wonder which problem we are solving with adding more little rules.
> Perhaps a future version of YANG will do away with prefixes but until
> this happens, I do not think we need to add more rules about how to
> choose prefixes. The original intend was that they are short to keep
> YANG snippets concise and easy to read.
> 
> /js
> 
> On Fri, Mar 15, 2024 at 01:02:58PM +0000, [e-mail]
> wrote:
> > Hi Andy,
> >
> > (changing the subject to ease tracking this)
> >
> > The thread I was referring is:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > archive.ietf.org%2Farch%2Fmsg%2Fnetmod%2F6VkSrroaxwXHSI19Jj0j-
> tbFCjA%2
> >
> F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cab1c68644b9f46df886f
> >
> 08dc44fb96df%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638461094563
> >
> 962002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> >
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=E0dsjDvDZ8KVY4UinoQWBFq
> > 5f%2BWG3bwREGRrMWlL9sA%3D&reserved=0
> >
> > I do personally think that it is a good guidance to prefix IETF
> modules with “ietf-“ and IANA-maintained ones with “iana-‘. This is
> consistent with the practice we followed recently for iana-maintained
> modules.
> >
> > If we recommend this prefix pattern, I’m afraid that we need to
> > revisit the text about short prefixes, e.g.,
> >
> > OLD:
> >    Prefix values SHOULD be short but are also likely to be unique.
> >    Prefix values SHOULD NOT conflict with known modules that have
> been
> >    previously published.
> >
> > NEW:
> >    Prefix values SHOULD be prefixed with “ietf-“ for IETF modules
> and
> >    “iana-“ for IANA-maintained modules. Prefix values SHOULD NOT be
> >    too long and SHOULD NOT conflict with known modules that have
> been
> >    previously published.
> >
> > Cheers,
> > Med
> >
> > De : Andy Bierman <[e-mail]> Envoyé : jeudi 14 mars 2024
> > 22:53 À : Mahesh Jethanandani <[e-mail]> Cc :
> BOUCADAIR
> > Mohamed INNOV/NET <[e-mail]>; [e-mail]
> > Objet : Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-
> rfc8407bis
> >
> > Hi,
> >
> > I cannot find this email wrt/ short prefixes
> >
> >
> >   *   (short/uniqueness of prefixes
> >
> > Other SDOs are using a prefix in their prefixes (e.g. openconfig).
> > It is common for servers to have both "if:interfaces" and "oc-
> if:interfaces" subtrees.
> >
> > It might be a good idea to have a guideline that all IETF YANG
> modules
> > SHOULD use the "ietf-" string in the module prefix.  This should
> > reduce the chance of name collisions between SDOs and vendors, and
> helps identify the module as an IETF module.
> >
> >
> > Andy
> >
> >
> >
> > On Tue, Mar 12, 2024 at 10:51 AM Mahesh Jethanandani
> <[e-mail]<mailto:[e-mail]>> wrote:
> > Hi Med,
> >
> > Thanks for driving this effort on updating RFC 8407.
> >
> > One additional change coming your way, is to address the question of
> how IANA is supposed to handle updates to IANA YANG modules. The YANG
> doctors are currently debating those changes. Once agreed, we will
> bring that discussion here, and will need to update rfc8407bis to
> provide guidance to authors who update an IANA module. Stay tuned.
> >
> > Cheers.
> >
> >
> > On Mar 12, 2024, at 5:00 AM,
> [e-mail]<mailto:[e-mail]>
> wrote:
> >
> > Hi all,
> >
> >
> >   *   A candidate -10 is ready to address 3 comments from Jan:
> >
> >      *   Long trees
> >      *   Updated security template
> >      *   Minor tweaks to Section 3.8
> >      *   The changes circulated on the list can be seen here:
> Compare Editor's Copy to
> Datatracker<https://eur03.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Fboucadair.github.io%2Frfc8407bis%2F%23go.draft-ietf-netmod-
> rfc8407bis.diff&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cab1c68
> 644b9f46df886f08dc44fb96df%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> 7C638461094563973290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ctWpUZX9p
> OsZHqYtzfYobIF5lIOAT68OE%2FhTSeDaxd4%3D&reserved=0>
> >
> >   *   Jan raised two other comments (short/uniqueness of prefixes +
> how to handle “not set”) but no changes were made per the feedback
> received on the list.
> >   *   Next steps:
> >
> >      *   Submit -10 right after IETF#119
> >      *   WGLC
> >
> > Cheers,
> > Med
> >
> >
> ______________________________________________________________________
> > ______________________________________
> >
> > 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.
> > _______________________________________________
> > netmod mailing list
> > [e-mail]<mailto:[e-mail]>
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai
> >
> r%40orange.com%7Cab1c68644b9f46df886f08dc44fb96df%7C90c7a20af34b40bfbc
> >
> 48b9253b6f5d20%7C0%7C0%7C638461094563983318%7CUnknown%7CTWFpbGZsb3d8ey
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> >
> C%7C%7C&sdata=leb7fW%2FMrfLSLfl7geos0%2FHtQv7Nut6wsufMaVfkfE8%3D&reser
> > ved=0
> >
> >
> > Mahesh Jethanandani
> > [e-mail]<mailto:[e-mail]>
> >
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]<mailto:[e-mail]>
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai
> >
> r%40orange.com%7Cab1c68644b9f46df886f08dc44fb96df%7C90c7a20af34b40bfbc
> >
> 48b9253b6f5d20%7C0%7C0%7C638461094563992463%7CUnknown%7CTWFpbGZsb3d8ey
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> >
> C%7C%7C&sdata=80%2Fzo0CWDtboXibwJQfTKVj8J8Y8sA1eWgbdAAo1lOg%3D&reserve
> > d=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.
> 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai
> >
> r%40orange.com%7Cab1c68644b9f46df886f08dc44fb96df%7C90c7a20af34b40bfbc
> >
> 48b9253b6f5d20%7C0%7C0%7C638461094564000130%7CUnknown%7CTWFpbGZsb3d8ey
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> >
> C%7C%7C&sdata=UW%2BD7wEooTG9UPBNDuokTbxxdrIQXE7Mtm4LrrF6BRs%3D&reserve
> > d=0
> 
> 
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
____________________________________________________________________________________________________________
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.