Hi Amanda, Thank you for the follow up.
A first candidate revised version to address your comments can be seen at: https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/amanda-iana/draft-ietf-netmod-rfc8407bis.txt Please see inline for more context. Cheers, Med > -----Message d'origine----- > De : Amanda Baber via RT <[email protected]> > Envoyé : jeudi 27 juin 2024 03:34 > Cc : [email protected]; BOUCADAIR Mohamed INNOV/NET > <[email protected]> > Objet : [IANA #1289473] Revision statements in IANA-maintained > YANG modules > > > 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: [Med] Sure. > > == > > 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.] [Med] For this one, I prefer we echo the exact guidance: "The "reference" substatement points specifically to the published module (i.e., IANA_FOO_URL_With_REV). It may also point to an authoritative event triggering the update to the YANG module. In all cases, this event is cited from the underlying IANA registry. If the update is triggered by an RFC, that RFC must also be included in the "reference" substatement." > > 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." > [Med] OK > == > > 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? [Med] This is explained in these IANA considerations: https://datatracker.ietf.org/doc/html/rfc6020#section-14. Updated the text you quoted to refer to that section. Per Section 4.27, rfc7950#section-11 naming rules for revised modules are to be followed, especially: Note that definitions contained in a module are available to be imported by any other module and are referenced in "import" statements via the module name. Thus, a module name MUST NOT be changed. Furthermore, the "namespace" statement MUST NOT be changed, since all XML elements are qualified by the namespace. 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? [Med] Good point. The document states that all revisions are currently maintained by IANA, e.g., All revisions of IETF and IANA published modules can be found at the YANG Parameters registry (https://www.iana.org/assignments/yang-parameters). However, we don't have any formal text to convey the current IANA practice, which may be seen as breaking this part from 6020: All module and submodule names in the registry MUST be unique. All XML namespaces in the registry MUST be unique. I suggest we formally tag this document as updating 6020 + make the changes in the NEW section "Revisions of Published Modules". > > 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." [Med] That is exactly the point. The authors should explicitly provide such guidance. > > 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. [Med] The guidance is to always include the url with specific version. If an RFC is also available, then include it. 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. [Med] That falls under this part of the guidance: "It may also point to an authoritative event triggering the update to the YANG module. In all cases, this event is cited from the underlying IANA registry." > > 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. [Med] I'm not sure to get the point here. If IANA accepts to list a github page in a registry that is also mirrored in an IANA module, I don't see an issue there. > > 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]' <iana-issues- > [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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fbo > > > ucadair.github.io%2Frfc8407bis%2Fdraft-ietf-netmod- > &data=05%7C02%7Cm > > > > ohamed.boucadair%40orange.com%7C5d22b175a4834d28604f08dc96546361% > 7C9 > > > > 0c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638550537096769289%7CUn > kno > > > > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h > aWw > > > > iLCJXVCI6Mn0%3D%7C40000%7C%7C%7C&sdata=VFtDB8Te35lsVeyVSjk%2BADWq > Cxq > > > E69K2509%2FROevzXY%3D&reserved=0 > > > 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://eur03.safelinks.protectio > n.o > > > > utlook.com/?url=https%3A%2F%2Fboucadair.github.io%2Frfc84&data=05 > %7C > > > > 02%7Cmohamed.boucadair%40orange.com%7C5d22b175a4834d28604f08dc965 > 463 > > > > 61%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63855053709677943 > 3%7 > > > > CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi > I6I > > > > k1haWwiLCJXVCI6Mn0%3D%7C40000%7C%7C%7C&sdata=Cav60OQhR4q%2FqcDyaE > gMX > > > PaqXaeRVK3sQ6tFieQI%2FYw%3D&reserved=0 > > > 07bis/draft-ietf-netmod- > > > > rfc8407bis.txt&url_2=https://eur03.safelinks.protection.outlook.c > om/ > > > > ?url=https%3A%2F%2Fboucadair.github.io%2Frfc8407bis%2Fmaint&data= > 05% > > > > 7C02%7Cmohamed.boucadair%40orange.com%7C5d22b175a4834d28604f08dc9 > 654 > > > > 6361%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638550537096785 > 871 > > > > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > TiI > > > > 6Ik1haWwiLCJXVCI6Mn0%3D%7C40000%7C%7C%7C&sdata=6JwqjRjfS4j5d40iBq > iMF > > > ZOjkM%2F4u6eiC0BJ3f9vogw%3D&reserved=0 > > > 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. ____________________________________________________________________________________________________________ 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]
