Re: [yang-doctors] Changing entries in IANA registries that modify enumerations (rfc5575bis)

Lada, Benoit,

Thank you for your comments.  I've not seen any objections to the suggested approach of fixing the IANA module so we will move forward with that approach.

Regards,
Rob

-----Original Message-----
From: Ladislav Lhotka <ladislav.lhotka@nic.cz> 
Sent: 15 May 2020 14:48
To: Rob Wilton (rwilton) <rwilton@cisco.com>; YANG Doctors <yang-doctors@ietf.org>
Cc: Alvaro Retana <aretana.ietf@gmail.com>
Subject: Re: [yang-doctors] Changing entries in IANA registries that modify enumerations (rfc5575bis)

Hi Rob,

RFC 8294 also states this in the IANA Considerations section:

   The name of the "enum" is the same as the corresponding Address
   Family or SAFI, except that it will be a valid YANG identifier in
   all lowercase and with hyphens separating individual words in
   compound identifiers.

It seems that this naming rule is not followed already in iana-routing-types@2020-05-12. I think it is better if the registry->YANG mapping is strict and unambiguous, because otherwise it may be difficult for IANA to maintain the module on their own.  

Regarding module update rules, I have been arguing for ages that these rules should not be part of the YANG language spec, and also that they should be applied only as recommendations.

Lada 

"Rob Wilton \(rwilton\)" <rwilton=40cisco.com@dmarc.ietf.org> writes:

> Hi,
>
> draft-ietf-idr-rfc5575bis.txt is changing the IANA definitions of two SAFIs:
>
>> rfc5575bis is only generalizing the description of the SAFIs:
>> 
>> OLD>
>> 133   IPv4 dissemination of flow specification rules
>> 134 	VPNv4 dissemination of flow specification rules
>> 
>> NEW>
>> 133   Dissemination of Flow Specification rules
>> 134   L3VPN Dissemination of Flow Specification rules
>
> I.e. they were originally defined as being IPv4 specific but are been generalized to cover IPv6 as well (which I understand is how they are already used/deployed).
>
>
> However, there is also an IANA YANG model defined using these entries (https://www.iana.org/assignments/iana-routing-types/iana-routing-types.xhtml), from RFC 8924.
>
> Currently in iana-routing-types@2020-05-12.yang, they are defined as:
>
>       enum ipv4-flow-spec-safi {
>         value 133;
>         description
>           "IPv4 Flow Specification SAFI.";
>       }
>
>       enum vpnv4-flow-spec-safi {
>         value 134;
>         description
>           "IPv4 VPN Flow Specification SAFI.";
>       }
>
>
> The proposal was to update these descriptions (which seems to do no harm):
>
>>       enum ipv4-flow-spec-safi {
>>              value 133;
>>              description
>>                "Dissemination of Flow Specification rules SAFI.";
>>            }
>>       enum vpnv4-flow-spec-safi {
>>              value 134;
>>              description
>>                "L3VPN Dissemination of Flow Specification rules SAFI";
>>            }
>
>
> But that leaves the enumerations with dubious names, and ideally the names would be fixed as well, e.g. to something like:
>
>>       enum ip-flow-spec-safi {
>>              value 133;
>>              description
>>                "Dissemination of Flow Specification rules SAFI.";
>>            }
>>       enum vpn-flow-spec-safi {
>>              value 134;
>>              description
>>                "L3VPN Dissemination of Flow Specification rules SAFI";
>>            }
>
> Clearly this is a violation of the RFC 7950 YANG update rules.
>
> The "deprecate the old and add a new entry" approach doesn't seem to work (given that the enum value is bound to the IANA SAFI defined value).
>
> However, it still feels to me that the right thing here is to allow the non-backwards-compatible change to fix the enumeration names (with an appropriate warning in the revision history).
>
> I would appreciate hearing the input/views of the YANG doctors on this.
>
> Regards,
> Rob
>
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67