Re: [Teas] IANA managed modules for TE object types

[[e-mail]]

Hi Tom, all,

You made interesting comments but we don't have established guidelines for setting IANA-maintained modules. I agree that enumerations can include the value statement, but still the mapping can be done by means of the description field. For both enumerations and identities, a label is needed to be used. If there is no such field in the registry, there is nothing wrong to use key strings from the description to unambiguously identify an entry.

I do think that we need more discussion is needed to weight the various approaches and derive some recommendations. I'm hopping netmod WG can take draft-boucadair-netmod-iana-registries so that Authors can be have clear and consistent design approaches. 

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[e-mail]> De la part de t petch
> Envoyé : mercredi 18 mai 2022 12:55
> À : Italo Busi <[e-mail]>; Tarek Saad
> <[e-mail]>; [e-mail]
> Cc : Adrian Farrel <[e-mail]>
> Objet : Re: [Teas] IANA managed modules for TE object types
> 
> On 16/05/2022 18:27, Italo Busi wrote:
> > Hi Tom,
> >
> > Please find below some replies to your comments
> >
> > Thanks, Italo
> >
> >> -----Original Message-----
> >> From: t petch <[e-mail]>
> >> Sent: lunedì 16 maggio 2022 10:51
> >>
> >> On 13/05/2022 18:59, Tarek Saad wrote:
> >>> Hi WG,
> >>>
> >>> During the review of draft-ietf-teas-yang-te, Adrian raised an
> >> important point about IANA managing some YANG module that
> models
> >> specific TE types. For example, ID draft-ietf-teas-yang-te was
> >> modelling 'no- path' some error reasons as listed in
> >> https://www.iana.org/assignments/pcep/pcep.xhtml#no-path-
> vector-tlv
> >> or association types as defined in
> >> https://www.iana.org/assignments/pcep/pcep.xhtml#association-
> type-field.
> >>
> >>> There are obvious advantages to having such YANG types in
> >> separate modules and letting IANA manage them. For example,
> >>>
> >>>     1.  Other TE modules can freely import such types modules
> >>> (without
> >> needing to import feature modules such as one defined in
> >> draft-ietf-teas- yang-te).
> >>>     2.  Allowing IANA to manage these modules may facilitate
> >>> extensions in the
> >> future (IANA can automatically ensure that IANA types and YANG
> module
> >> are in sync).
> >>>
> >>> The authors discussed this suggestion and would like to
> proceed with
> >>> it, but
> >> want to make sure this is the recommended approach for other
> types
> >> that are managed by IANA and may be modelled in YANG in the
> future.
> >>
> >> I struggle to make sense of this.
> >>
> >> When I look for association-type in teas-yang-te, I find it
> refers to
> >> RFC8776 so creating an IANA-maintained module for it would seem
> a few
> >> years too late.
> >>
> >
> > [Italo Busi]
> > This is a bit unfortunate. However, the association-type
> identity defined in RFC 8776 is not yet used by any standard model
> so we can consider this new approach deprecate the corresponding
> identities in draft-busi-teas-te-types-update which has been
> recently proposed to TEAS WG.
> 
> Weeel, set off on the wrong direction and you end up in Japan
> instead of America; nothing wrong with Japan, except when it is LA
> or SF that you want.
> 
> In the early days of te-types, I did go through all the
> MPLS/GMPLS/PCE etc registries (some of which I was involved with
> 20 years ago) and noted considerable overlap between te-types and
> those registries; I do not recall what I posted to the list about
> it but certainly wondered at not involving the WG who had created
> the IANA registries in creating a YANG version of the registries.
> I still think that the WG Chairs of TEAS should tell their PCE
> counterparts what they have in mind in this instance.
> 
> Why stop at associations?  Probably because everything else has
> been implemented and so is harder to change:-( Such is the way of
> working of the IETF but I think that the decision not to do
> anything about the other registries should be a conscious one at
> this time.
> 
> Also, I see YANG identity as a bad fit for a registry with a
> policy of 'Standards Action' - enumeration would seem a better
> fit.
> 
> Most IANA registries are based on numeric values; YANG is not, so
> there needs to be a mapping, between number and identifier string,
> which te-types ignores.  YANG enumeration at least can document
> the mapping.
> 
> And for any new value, a new identifier string is required.  I see
> one I-D devolving that action to IANA; wrong, IMHO, outside their
> remit.
> 
> Tom Petch
> 
> p.s. the revised te-types needs work.  It lacks several dozen
> references and needs action by IANA.
> 
> > [/Italo Busi]
> >
> >> Politically, the IPR rules of the IETF allow you to go ahead
> and make
> >> an IANA- maintained module but I find such behaviour not just
> >> discourteous but likely to induce errors.  If this is to
> progress,
> >> then it should be in the PCE WG with their active support and
> technical input.
> >>
> >> For example, association-type in IANA has an entry such as
> >> 5 Double-sided Bidirectional LSP Association.
> >> This is useless for YANG.  YANG is character-oriented and the
> nodes
> >> in
> >> RFC8776 are identity.  To identify entries by numeric value,
> you
> >> should use enumeration not identity and change RFC8776, teas-
> te, and
> >> perhaps all the modules that augment it, to suit.  This has
> added value with change control.
> >> Anyone can add anything anywhere to an identity.  This is an
> >> advantage when vendors may want to add their own values.  Here
> the
> >> PCEP registry is Standards Action so the higher bar of
> enumeration,
> >> requiring a revised module, is a better fit.
> >>
> >> For an identity, then that entry has to be turned into a
> unique,
> >> relevant, short string.  Who has the technical skill to do that
> for
> >> Double-sided Bidirectional LSP Association?
> >>
> >> I would not trust IANA to do that without expert input from
> e.g. the
> >> PCE WG so it should be the PCE WG that does the related work.
> I
> >> think that that could involve adding a new column to the
> existing
> >> IANA registry which provides the YANG identifying string and so
> >> provides the mapping between existing value and string.
> >>
> >
> > [Italo Busi]
> > I agree with you that identities would be preferable than an
> > enumeration to give more implementation flexibility
> >
> > The proposal to add a new column to the IANA registry looks good
> to me
> > [\Italo Busi]
> >
> >> Tom Petch
> >>
> >>> Regards,
> >>> Tarek (for the co-authors of draft-ietf-teas-yang-te)
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Teas mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/teas
> >>>
> >>
> >
> > .
> >
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas

_________________________________________________________________________________________________________________________

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.