Hi Amanda,
Good inputs.
Added the follow text as a new bullet:
NEW:
- If a new registration uses an identifier that does not comply
with the naming conventions listed in Section 4.3.1, IANA
should check if a guidance to generate legal identifiers was
supplied in the RFC that specified the initial version of the
module. If no such guidance is available, IANA should check
the latest revision of the IANA-maintained module for similar
patterns. If failed, IANA should seek advice from relevant
registry experts (e.g., designated experts for a registry with
Expert Review policy (Section 4.5 of [RFC8126]) or responsible
Area Director for a registry with IETF Review (Section 4.8 of
[RFC8126]) or Standards Action ((Section 4.9 of [RFC8126]))).
Better?
Cheers,
Med
PS: The full diff can still be seen using the same URL:
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-follow-up-on-expanding-numbers/draft-ietf-netmod-rfc8407bis.txt
> -----Message d'origine-----
> De : Amanda Baber via RT <iana-iss...@iana.org>
> Envoyé : vendredi 6 septembre 2024 21:39
> À : kent+i...@watsen.net; BOUCADAIR Mohamed INNOV/NET
> <mohamed.boucad...@orange.com>
> Cc : netmod@ietf.org
> Objet : [IANA #1373241] RE: [netmod] Regarding draft-ietf-netmod-
> rfc8407bis
>
>
> Hi,
>
> The new text works, but I'm not sure whether it should be
> included here. See [AB] inline.
>
> > 1) Regarding "For example, authors of a module with such
> identifiers
> > have to indicate...”, I’m unsure how the registrant is suppose
> to
> > propose valid YANG identifiers. First, I wonder if the
> registrant
> > would even be aware of the existence of a YANG module for the
> > underlying registry. Next, I wonder if the registrant would
> know
> > what are valid YANG identifier values.
> >
> > [Med] Fully agree that the registrant of a new entry does not
> (and
> > does not even need to) know the existence of the IANA-
> maintained
> > module. The instruction here is not for those.
> >
> > What I do know, because it happened to me, if that my using the
> > underlying value caused a YANG error. This is what I suspect
> will
> > happen to IANA. That is, they’ll first try the underlying
> value and
> > get a module-validation error…
> >
> >
> > Thus I wonder if the instructions should be more in the form of
> “do
> > this when an error occurs”, instead of instructions that
> attempt to
> > proactively determine the issues before they occur?
> >
> > [Med] The proactive approach has the merit to ensure consistent
> naming
> > conventions and straightforward actions for IANA. I think that
> we
> > should encourage authors to look into this. There might be
> errors if
> > the naming conventions listed in Section 4.3.1 are not
> followed. I
> > have no problem to reword the text so that this can be easily
> consumed
> > by IANA as well. I hope Amanda can share her
> feedback/preference.
>
> [AB] I see how this advice would work if IANA were creating the
> module, but I'm a little less clear on how it works for
> anticipating future underlying registrations.
>
> If an identifier won't validate, IANA will already know that they
> have to take some action to remedy it. The first step would be to
> check whether the module had already solved the problem for an
> earlier occurrence of "3des-*". If there were no such existing
> registration, and knowing that "3" might be rendered as either
> "triple" or "three," instead of checking the RFC that created the
> module for advice about a string that didn't appear in the
> underlying registry at the time of publication, we would more
> likely ask the YANG doctors how to proceed. (If the underlying
> registry had designated experts, we might check with them first.)
>
> If the authors for a specific module already know that there are
> that likely to be more "3des-*" registrations in the future,
> there's no harm in calling it out (as long as they don't appear
> to be implying that the "triple-" solution should be applied to
> any leading number), but in general, it might be better to give
> IANA advice about how to resolve identifier questions in general
> (e.g., check the existing module, contact the YANG doctors or
> other appropriate party).
>
> 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 -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
