Hi Med, Sorry about my lateness here.
Section 4.30.3 seems to be directed at both authors and IANA, but IANA usually doesn't look to implement information that isn't included in or pointed to by the IANA Considerations section. I'd like to ask that the IANA Considerations section include a sub-section that says something like this: == IANA should refer to Section 4.30.3 for information necessary to populate revision statements and identity and enumeration [enum?] sub-statements in IANA-maintained modules. In particular, the following should be noted: * When an underlying registration is deprecated or obsoleted, a corresponding 'status' sub-statement should be added to the identity or enumeration statement. * When the registration doesn't refer to an RFC, the reference statement should point to the URL for the module itself. [If this is correct. I've included a question about this at the end of the email.] In addition, when the module is published, IANA must add the following notes to the YANG Module Names registry and the underlying registry (if applicable), respectively: * "New values must not be directly added to the "iana-foo" YANG module. They must instead be added to the "foo" registry." * "When this registry is modified, the YANG module "iana-foo" [IANA_FOO_URL] must be updated as defined in RFC IIII." == This would help us pull out the information we'll need to maintain a short internal help document. When we update a module, we create new statements by copying the structure of an existing statement, so all we really need to highlight here is information that it may not be possible to derive from the existing module (the fact that the "status" field exists, what to do when the registration doesn't refer to an RFC). A big issue here is that IANA operations staff (as opposed to technical staff, or the VP) don't know the YANG language. We're all liberal arts majors who have at most taken some programming classes and a couple of networking classes at a community college or UCLA Extension. As such, the IANA-relevant information in this document has taken some time to pick out. A few other issues: Section 4.1, Module Naming Conventions: the document states that "All published module names MUST be unique. For a YANG module published in an RFC, this uniqueness is guaranteed by IANA." What does "guaranteed" mean here? IANA doesn't currently check for this. We would assume that the new module was a replacement for the existing one, and add it to the registry (without removing the existing one, because we've been instructed to leave all previous versions in the registry rather than replace them. It should probably be noted that that instruction hasn't been documented in an RFC). Should we check for that? If so, what would we look for? Section 4.30.3: there's an issue with the paragraph "If the name in the IANA registry does not comply with the naming conventions listed in Section 4.3.1, the procedure MUST detail how IANA can generate legal identifiers from such a name. For example, if the name begins with a number, it is RECOMMENDED to spell out the number when used as an identifier (e.g., "3des-cbc" will be "triple-des-cbc" (Section 6.3 of [RFC4253]))." This isn't an ideal example, because IANA would in fact not know that "triple" is preferred to "three." Finally: I'm confused by the revision statement examples that refer to both an RFC and the module URL, as I thought the latter was only to be used when the registration doesn't have an RFC to point to. Or is that "an RFC or any other spec"? (Specs, I should add, can range from ISO documents to someone's website or github page.) Section 4.30.3 provides examples of both, which doesn't tell IANA what to do. Also, in the lists of sub-statements for identity and enum statements, the description for "reference" is currently "Replicates the reference(s) from the registry with the title of the document(s) added," but this seems misleading. I could imagine, for example, finding that text and assuming that this was the definitive answer, even if it was the document was a github page, and assuming that the document wasn't going to go on and also add that the reference could just point to the module. thanks, Amanda On Fri May 31 06:03:02 2024, [email protected] wrote: > Hi Amanda, > > Any update about this point? Do you still think some change is needed? > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : BOUCADAIR Mohamed INNOV/NET > > Envoyé : lundi 6 mai 2024 17:18 > > À : '[email protected]' <[email protected]> > > Objet : RE: [IANA #1289473] Revision statements in IANA- > > maintained YANG modules > > > > Hi Amanda, > > > > Apologies for the delay to reply as I was out of office last > > week. I will also be unavailable most of this week as well. > > > > We do have this section > > https://boucadair.github.io/rfc8407bis/draft-ietf-netmod- > > rfc8407bis.html#name-guidance-for-writing-the-ia with a set of > > instructions that are meant to feed the maintenance. However, I'm > > not sure if that is what you are looking for. > > > > The only change I made so far can be tracked here: > > https://author- > > tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc84 > > 07bis/draft-ietf-netmod- > > rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/maint > > enance-instructions/draft-ietf-netmod-rfc8407bis.txt > > > > I can make more changes once I have a better understanding of the > > concern :-) > > > > Thank you. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Amanda Baber via RT <[email protected]> > > Envoyé : > > > mercredi 1 mai 2024 03:19 Cc : BOUCADAIR Mohamed INNOV/NET > > > <[email protected]> Objet : [IANA #1289473] Revision > > > statements in IANA-maintained YANG modules > > > > > > > > > Hi Med, > > > > > > A note about draft-ietf-netmod-rfc8407bis: > > > > > > It's easy to find information about creating IANA-maintained > > modules, > > > but information about maintaining them isn't as easy to find. I > > wonder > > > if in addition to telling us what to register, the IANA > > Considerations > > > section might also list the points that IANA needs to take away > > from > > > the document (perhaps with pointers to the appropriate > > > section/subsections). > > > > > > thanks, > > > Amanda > ____________________________________________________________________________________________________________ > 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 -- [email protected] To unsubscribe send an email to [email protected]
