<#secure method=pgpmime mode=sign>
> On Mon, Jun 28, 2021 at 12:39:38PM -0400, Michael Richardson wrote:
>>
>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote:
>> >> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote:
> <snip>
>> > You revise RFC 8366 and do the following:
>>
>> > - You define an IANA maintained module defining the enumeration type.
>>
>> This is the part that I don't know to do.
>> https://www.rfc-editor.org/rfc/rfc7950.html#section-9.6
>> says nothing about IANA. Is RFC7224 the model for this?
>>
>> What document am I missing here?
> Yes, RFC 7224 defining the iana-if-type module may serve as a
> template. There are a couple of IANA maintained YANG modules, I am not
> sure whether we have a good place listing them all. Well, you can
> filter out the iana- modules from this list:
Okay, I understand now.
RFC7224 is an *IANA* maintained YANG module. When new allocations are made,
then IANA rewrites the YANG module to include the new items.
It's not a YANG module that imports from a IANA registry, which I think we
have no YANG way to do that.
RFC7224 seems to use identity to create new subclasses.
RFC7217 seems to use typedef and feature.
Based upon my understanding, perhaps we don't need to revise RFC8366 completely,
it might be that we can just update it to include IANA Considerations and
turn the ietf-voucher YANG module into an IANA maintained YANG module?
That just avoids opportunity for more text churn.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
