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

Hi Tom,

Please find below some replies to your comments

Thanks, Italo

> -----Original Message-----
> From: t petch <ietfa@btconnect.com>
> Sent: lunedì 16 maggio 2022 10:51
> To: Tarek Saad <tsaad.net@gmail.com>; teas@ietf.org
> Cc: Adrian Farrel <adrian@olddog.co.uk>
> Subject: Re: [Teas] IANA managed modules for TE object types
> 
> 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.
[/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
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> >
> 