Hi Kent,
Please see inline.
Cheers,
Med
De : Kent Watsen <kent+i...@watsen.net>
Envoyé : vendredi 6 septembre 2024 14:24
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>
Cc : iana-iss...@iana.org; netmod@ietf.org
Objet : Re: [IANA #1373241] [netmod] Regarding draft-ietf-netmod-rfc8407bis
Hi Med,
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.
2) Regarding this following
-- If a name in the IANA registry does not comply with the
-- YANG naming conventions, add details how IANA can generate
-- legal identifiers.
Who is this comment addressed too? IANA? Is the idea that IANA leaves a
comment for themselves?
[Med] This is part of a template to be used by the authors of the RFC that
defines the initial version. This is to remind the authors to make that check
and supply instructions if needed.
Kent // contributor
On Sep 6, 2024, at 5:56 AM,
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote:
Hi Amanda,
Thanks for these inputs.
OK to add 6to4 as another example. It is actually a good example as we do have
two ways to spell it out in existing RFCs :-)
I updated the text to better insist that the effort should be on the authors
side to make the IANA task easy. Also, updated the template with a placeholder
for that check. Please see the proposed changes 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-follow-up-on-expanding-numbers/draft-ietf-netmod-rfc8407bis.txt
Hope this is better.
Cheers,
Med
-----Message d'origine-----
De : Amanda Baber via RT <iana-iss...@iana.org<mailto:iana-iss...@iana.org>>
Envoyé : vendredi 6 septembre 2024 07:52
À : kent+i...@watsen.net<mailto:kent+i...@watsen.net>; BOUCADAIR Mohamed
INNOV/NET
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>
Cc : netmod@ietf.org<mailto:netmod@ietf.org>
Objet : [IANA #1373241] RE: [netmod] Regarding draft-ietf-netmod-
rfc8407bis
Hi Med, Kent,
I apologize for missing this.
In the 4.30.3 note about creating names, a replacement like this
might be better for IANA:
OLD: (e.g., "3des-cbc" will be "triple-des-cbc" (Section 6.3 of
[RFC4253]))
NEW: (e.g., "3des-cbc" will be "triple-des-cbc" (Section 6.3 of
[RFC4253]); "6to4" will be "sixToFour")
The "6to4"/"sixToFour" example is taken from the iana-if-type
module, published in Section 2 of RFC 7224.
The reasoning here is that the note says that "the procedure MUST
detail how IANA can generate legal identifiers from such a name."
Because we're being told that this is an example of an IANA
Considerations section providing sufficient detail for future
registrations, it would be helpful for us if the note were to
acknowledge, at least implicitly, that future authors may not be
able to supply a single naming pattern that we can always apply
automatically.
The missing piece of information here, I think, is that IANA
operations staff didn't know (and, in the future, may not know
again) that "3des" is pronounced "triple-des." As such, it's
possible for us to read the current example and wonder whether
IANA is being told to replace any leading number in an identifier
with a multiplicative.
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 -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
