Hi Tom,
This part from 8407 is worth to be considered:
If an appropriate derived type exists in any standard module, such as
[RFC6991], then it SHOULD be used instead of defining a new derived
type.
Unless I'm mistaken, the idr I-D defines a new identity afi-safi which is not
**directly** defined in RFC8294. However, I do think their design is suboptimal
as we can reuse the existing typedefs from RFC8294, but calling individually
the afi and safi.
Note that RFC4760 says the following:
====
Address Family Identifier (AFI):
....
Presently defined values for the Address Family Identifier
field are specified in the IANA's Address Family Numbers
registry [IANA-AF].
and
As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
attributes contain the Subsequence Address Family Identifier (SAFI)
field. The SAFI name space is defined in this document. The IANA
registered and maintains values for the SAFI namespace as follows:
===
Freezing afi-safis in an IETF-maintained module is indeed an example of designs
that draft-boucadair-netmod-iana-registries is trying to avoid.
Cheers,
Med
> -----Message d'origine-----
> De : tom petch <[email protected]>
> Envoyé : lundi 28 mars 2022 12:38
> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>;
> [email protected]; Jürgen Schönwälder <j.schoenwaelder@jacobs-
> university.de>
> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
>
> From: netmod <[email protected]> on behalf of Jürgen Schönwälder
> <[email protected]>
> Sent: 25 March 2022 10:37
>
> Thanks Lada,
>
> this is useful input I think.
>
> Another thing that we experienced in some corners of the IETF is that
> IANA registries are often tied to specific protocols and it is sometimes
> tempting to reuse a registry for a sligthly different purpose. This can
> cause problems down the road when for example definitions stop to make
> sense for the protocol the registry was created for (i.e., they should
> move to deprecated or obsolete) but other uses of the registry would
> still need the definition.
>
> This is not really an YANG specific issue but more a general issue
> whenever people try to reuse existing registries. If there are many uses
> of a given registry, you may end up with many (sometimes
> overlapping) definitions out of which only a subset make really sense
> for a given use case. In other words, generalizing the use of an
> existing registry beyonds its original scope can cause serious problems
> down the road. Again, this is not really YANG specific, but it has shown
> up with YANGified registries.
>
> <tp>
>
> I just fell over a twist to this. There is an IANA-maintained module of
> address family as enumerations. bgp-model reinvents part of this as
> YANG identity and at least one other WG has imported the bgp-model
> version into its work.
>
> I have queried this on the IDR list but can imagine the response I will
> get, along the lines of the issues in this thread:-(
>
> Tom Petch
>
> /js
>
_________________________________________________________________________________________________________________________
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]
https://www.ietf.org/mailman/listinfo/netmod
