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

[t petch <[e-mail]>]

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.

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.

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
>