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

[t petch <[e-mail]>]

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
>>>
>>
>
> .
>