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, mohamed.boucad...@orange.com wrote: > Hi Andy, > > (changing the subject to ease tracking this) > > The thread I was referring is: > https://mailarchive.ietf.org/arch/msg/netmod/6VkSrroaxwXHSI19Jj0j-tbFCjA/ > > 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 <a...@yumaworks.com> > Envoyé : jeudi 14 mars 2024 22:53 > À : Mahesh Jethanandani <mjethanand...@gmail.com> > Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > netmod@ietf.org > 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 > <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> 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, > mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 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://boucadair.github.io/rfc8407bis/#go.draft-ietf-netmod-rfc8407bis.diff> > > * 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 > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > > > Mahesh Jethanandani > mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > ____________________________________________________________________________________________________________ > 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
