Re: [CCAMP] What to reference when importing an IANA module?

[[e-mail]]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : tom petch <[e-mail]>
> Envoyé : jeudi 12 janvier 2023 14:18
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> Italo Busi <Italo.Busi=[e-mail]>;
> [e-mail]
> Cc : [e-mail]
> Objet : Re: What to reference when importing an IANA module?
> 
> From: netmod <[e-mail]> on behalf of
> [e-mail] <[e-mail]>
> Sent: 12 January 2023 13:09
> 
> Hi Italo,
> 
> There is currently no explicit (*) guideline for this, but this is
> a point I can add to https://datatracker.ietf.org/doc/draft-
> boucadair-netmod-iana-registries/.
> 
> Many RFCs are referencing the RFC that specified the initial
> version of the IANA module: rfc9127, rfc9129, rfc9130, rfc9291,
> rfc9132, etc.
> 
> However, my take on this would be to recommend referencing the
> IANA as the authoritative source but allow for also referencing
> the RFC that defines the initial version of the module.
> 
> <tp>
> Yes and no.  The RFC version is obsolete as soon as it is
> published since change  control is then with IANA.

[Med] It is not true that the RFC is obsoleted: the RFC may include a script to generate an IANA module from a registry + the module is removed from the RFC version. That's said, I agree with you that we need to encourage referencing the IANA URL rather than the RFC.

The "may reference RFC" part I mentioned is basically to not declare the long list of RFCs out there (rfc9127, rfc9129, rfc9130, rfc9291, rfc9132, etc.) as not compliant. What about the following language: 

    If an IANA-maintained module is imported by another module, a
    normative reference with the IANA URL from where to retrieve the
    IANA-maintained module SHOULD be included.  Although not encouraged,
    referencing the RFC that defines the initial version of the IANA
    module is acceptable in specific cases (e.g., the imported version is
    specifically the initial version, the RFC includes useful description
    about the usage of the module).


 We know that,
> users in other SDOs likely do not and since RFC are much easier to
> access than IANA websites such users will be tempted to reference
> and use the obsolete version..  The RFC is of course referenced in
> the IANA website and that is how we should force users to access
> it so that they understand that the RFC version is obsolete.
> 
> Tom Petch
> 
> Cheers,
> Med
> 
> (*) other than this part from RFC8407:
> 
> 
> 
>    The reference MUST
> 
>    correspond to the specific module version actually used within
> the
> 
>    specification.
> 
> 
> De : netmod <[e-mail]> De la part de Italo Busi
> Envoyé : jeudi 12 janvier 2023 13:21 À : [e-mail] Cc :
> [e-mail] Objet : [netmod] What to reference when importing
> an IANA module?
> 
> Hi all,
> 
> Happy New Year
> 
> During a WG adoption poll we have received a comment that the URL
> should be added in the reference statement when importing a YANG
> module maintained by IANA and we are not sure how to address this
> comment
> 
> See:
> https://mailarchive.ietf.org/arch/msg/ccamp/zD6gAfEUlYJ4W3qQlz6Y_g
> fX5TY/
> 
> I have checked RFC8407 but I have not found any guideline on what
> to reference when importing an IANA module
> 
> I have checked a couple of examples I knew (RFC8343 and RFC8348)
> and noted that the IANA modules are imported with no reference
> 
> I have also noted that within the IANA YANG model registry, the
> reference for the IANA modules is the RFC where the module has
> been initially defined:
> 
> https://www.iana.org/assignments/yang-parameters/yang-
> parameters.xhtml
> 
> What would be your suggestion?
> 
> Are there any guidelines I have missed?
> 
> Do you know if there are other examples of published RFCs
> importing an IANA module?
> 
> Thanks in advance
> 
> Italo
> 
> 
> 
> __________________________________________________________________
> _______________________________________________________
> 
> 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.