[alto] ALTO O&M data model: IANA related data types

[Jensen Zhang <[e-mail]>]

Hi Kai,

Many thanks for sharing your thoughts. I separate this discussion into an
individual thread so that we can focus on this specific issue without
broadcasting to discussions of other issues.

See my comments below.

On Tue, Sep 6, 2022 at 9:49 PM <[e-mail]> wrote:

> Hi Jensen, Qin and all,
>
>
> Thanks for the discussion. Please see my comments inline.
>
>
> Best,
>
> Kai
>
> -----Original Messages-----
> *From:*"Jensen Zhang" <[e-mail]>
> *Sent Time:*2022-09-06 21:13:01 (Tuesday)
> *To:* "Qin Wu" <[e-mail]>
> *Cc:* "IETF ALTO" <[e-mail]>
> *Subject:* Re: [alto] Open discussions of ALTO O&M data model
>
> Hi Qin,
>
> Sorry for my late reply. See my comments inline.
>
>
> On Sun, Aug 21, 2022 at 8:44 AM Qin Wu <[e-mail]> wrote:
>
>> Hi, Jensen:
>>
>> Thank for summarizing the discussion in last IETF meeting, please see my
>> comments inline.
>>
>>
>>
>> *发件人:* alto [mailto:[e-mail]] *代表 *Jensen Zhang
>> *发送时间:* 2022年8月16日 21:04
>> *收件人:* IETF ALTO <[e-mail]>
>> *主题:* [alto] Open discussions of ALTO O&M data model
>>
>>
>>
>> Hi ALTOers,
>>
>> >From the WG session in IETF 114, we had a lot of discussions about the
>> open issues for ALTO O&M. Authors appreciate all the comments and are
>> working on the next revision.
>>
>> We quickly summarize the major debates and are willing to have more
>> discussions to move this work forward. To be more efficient, we may
>> separate the discussions to different threads later.
>>
>> 1. How to handle data types defined by IANA registries
>>
>> There are actually two arguments:
>>
>> 1.a. Which statement is better used to define the IANA-related data types
>> (e.g., cost modes, cost metrics)? Two options: enumeration typedef or
>> identity
>>
>> The main limitation of the enumeration is the extensibility. As ALTO may
>> have multiple ongoing extensions, it will be required to add new private
>> values for existing data types for experimenting purpose. Identity is
>> better choice to support this.
>>
>> 1.b. Whether put the data type definitions to an IANA-maintained YANG
>> module
>>
>> >From the guidelines provided by Med (
>> https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries-03),
>> IANA-maintained module is RECOMMENDED.
>> *[Qin Wu] *If you chose to use identity data type, I think it is not
>> necessary for you to use IANA maintained YANG module, IANA maintained YANG
>> module allows you later on make update to the data type if needed.
>>
>> *If you don’t expect to have frequent changes to the data types, It looks
>> identity is best option but not necessary to create IANA maintained module.*
>>
>> *Otherwise, it seems overdesign to me.*
>>
>
> From my understanding, identity is to allow non-standard YANG modules to
> add new values to the registry. IANA maintained module is to allow IANA to
> keep the registry updated by standard YANG modules. So I don't think
> creating IANA maintained module is overdesign.
> I think the point to use the IANA maintained module is that updates to the
> data types defined by IANA registry would be more frequent than updates to
> the OAM YANG module.
> But let's see how other ALTOers will react.
>
>
>
> I remember that we had some discussion on this issue during IETF 114. The
> idea of using identity instead of enum is to enable new values to be used
> without breaking other packages that depend on the module that defines the
> enum.
>
>
> However, it may be possible that IANA manages not one but multiple
> modules. Then new extensions can be added as individual modules and
> packages.
>
>
> An example can be seen below:
>
>
> Before module2 is being standardized:
>
> - module1 is a standard module managed by IANA
>
> - module2 is a private module with some extensions
>
>
> module1 (iana-alto-base-xxx)        module2 (private-alto-ext-xxx)
>
>    |                                                 |
>
>    |----------------------------------------\        |
>
>    v                                        v        v
>
> alto-server1                              alto-server-2
>
>
> After:
>
> - module1 is a standard module managed by IANA
> - module2 becomes a standard module managed by IANA
>
>
>
> module1 (iana-alto-base-xxx)        module2 (iana-alto-ext-xxx)
>
>    |                                                 |
>
>    |----------------------------------------\        |
>
>    v                                        v        v
>
> alto-server1                              alto-server-2
>
>
> Then module1 is untouched and alto-server1 can continue to work without
> the need to update its own dependency. If alto-server1 wants to support the
> extension, it can add module2 to its dependencies.
>
If iana-alto-ext-xxx is optional, I think it is OK. But if it is mandatory,
I think it should be merged into iana-alto-base-xxx to guarantee
consistency between alto-server-1 and alto-server-2.

I think the main benefit of using the IANA-maintained YANG module is that
the upstream YANG module does not need to be updated if only data types
defined by the IANA-maintained module are updated.

The setting would be as follows:

In the beginning,

module1 ([e-mail])
    |
    v
module0 ([e-mail])
    |
    v
alto-server-1

When some new experimental extension introduces new values to
IANA-maintained data types:

module1 ([e-mail])
    |------------------- module2 (private-alto-types-ext.yang)
    v
module0 ([e-mail])
    |
    v
alto-server-1

After a while, the extension becomes standard:

module1 ([e-mail]) <-- new revision
    |
    v
module0 ([e-mail])
    |
    v
alto-server-1

As you can see, module0 has no need to update.

Cheers,
Jensen