Re: [netmod] IANA registries
On 29. 11. 21 14:32, Robert Varga wrote: On 26/11/2021 09:30, Ladislav Lhotka wrote: And what do yo do with Early Allocation, which can last more than a year? Sorry, I am not familiar with early allocations, what could be the problem here? The problem is that early allocations are temporary and automatically expire in 12 months (relinquishing the code point) unless refreshed by the requester -- see https://www.rfc-editor.org/rfc/rfc7120#section-3.3 for details. I see. So if the temporarily allocated code point disappears from the registry, it won't be present in the YANG module either, if it is generated later. If YANG was able to read the registry directly, it would be the same. Cheers, Lada Regards, Robert ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
On 26/11/2021 09:30, Ladislav Lhotka wrote: And what do yo do with Early Allocation, which can last more than a year? Sorry, I am not familiar with early allocations, what could be the problem here? The problem is that early allocations are temporary and automatically expire in 12 months (relinquishing the code point) unless refreshed by the requester -- see https://www.rfc-editor.org/rfc/rfc7120#section-3.3 for details. Regards, Robert OpenPGP_signature Description: OpenPGP digital signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
Hi Lada, > On 2021-11-26, at 09:48, Ladislav Lhotka wrote: > > Carsten Bormann writes: > >> On 2021-11-24, at 09:13, Ladislav Lhotka wrote: >>> >>> Please let me know what you think about this. >> >> I think it is amazing. >> >> So for each registry, you have >> >> — manually extracted an information model and kept that in your head, > > Well, my old head doesn't serve me that well anymore, I was just looking into > the registry web page and XML. Indeed, so you had to apply human intelligence to produce information that is not available for the registry. >> — written code that translates the information you could extract from the >> XML form of the registry into a YANG data model (note that this data model >> is not defining the registry, but it is the translated content of the >> registry) > > Right, and IANA needn't be involved at all. In the long run, we will need to make sure we actually capture the information model for registries (at the time the registries are created and updated, when the experts are in the house). >> This is certainly highly useful. >> It also requires to essentially start from scratch for each new registry. > > Registry schemas are quite diverse, so a universal translation procedure > isn't possible. (That’s why I said we need to capture the information model. There is not a single one that applies to every registry.) > Also, some decisions may be necessary on the YANG side - for example, whether > the registry records are to be represented as enums or identities. Right, that is essentially the the IM ➔ DM mapping, and that needs to be done for each kind of DM (unless the IM already contains enough hints to carry this out by default). > In most cases, writing a registry-specific translation isn't difficult and > amounts to copying Makefile and XSLT stylesheet templates, editing parameters > in the Makefile and writing a few XSLT lines. I’m not questioning this, I just note that this is a mostly manual process that will be hard to maintain in the long run. >> Shouldn’t registries come with a machine readable information model? > > Actually, RELAX NG schemas are available, for example > > https://www.iana.org/assignments/dns-parameters/dns-parameters.rng These are data models for the registry page, not the underlying information models. > They are useful for clarifying what to expect in the registry but don't help > much with automating the translation. (Because the IM info is missing.) >> Shouldn’t it then be “easy” to build a generic tool that creates a YANG >> model out of the data in the registry? > > Ideally, YANG might be able to directly "import" registries, but this is > quite difficult to achieve because registries are not very uniform. … and you’d need the IM info (and any DM mapping hints). .oOo. I don’t want to hold up this effort by trying to do this properly, but I note that YANG is not the only target DM that registries would need to translate info. (And you’ll note that I’m thinking like an SDF author here…) Grüße, Carsten ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
Carsten Bormann writes: > On 2021-11-24, at 09:13, Ladislav Lhotka wrote: >> >> Please let me know what you think about this. > > I think it is amazing. > > So for each registry, you have > > — manually extracted an information model and kept that in your head, Well, my old head doesn't serve me that well anymore, I was just looking into the registry web page and XML. > — written code that translates the information you could extract from the XML > form of the registry into a YANG data model (note that this data model is not > defining the registry, but it is the translated content of the registry) Right, and IANA needn't be involved at all. > > This is certainly highly useful. > It also requires to essentially start from scratch for each new registry. Registry schemas are quite diverse, so a universal translation procedure isn't possible. Also, some decisions may be necessary on the YANG side - for example, whether the registry records are to be represented as enums or identities. In most cases, writing a registry-specific translation isn't difficult and amounts to copying Makefile and XSLT stylesheet templates, editing parameters in the Makefile and writing a few XSLT lines. > Shouldn’t registries come with a machine readable information model? Actually, RELAX NG schemas are available, for example https://www.iana.org/assignments/dns-parameters/dns-parameters.rng They are useful for clarifying what to expect in the registry but don't help much with automating the translation. > Shouldn’t it then be “easy” to build a generic tool that creates a YANG model > out of the data in the registry? Ideally, YANG might be able to directly "import" registries, but this is quite difficult to achieve because registries are not very uniform. Thanks, Lada > > Grüße, Carsten > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
tom petch writes: > From: netmod on behalf of Ladislav Lhotka > > Sent: 24 November 2021 08:13 > > Hi, > > I tried to generalize the approach of RFC 9108 and develop XSLT stylesheets > for generating YANG modules directly from IANA registries. The results are in > this GitHub project: > > https://github.com/llhotka/iana-yang > > So far I have processed 22 registries - most of them are related to DNS, but > I also tried to include a few from other areas. After cloning the project, > all YANG modules can be generated by running "make" in the top-level > directory. > > Adding a new registry is usually quite simple, although some hide nasty > surprises such as duplicate entries. Also, in most cases it is quite clear > how to do the translation, but sometimes input from domain experts might be > needed. > > I can see two immediate advantages of this approach: > > * There is a single source of truth - the registry itself; IANA needn't > maintain the YANG module separately. > > * The initial revision of a registry-based YANG module needn't be published in > an RFC that is not intended to be updated. There are concerns that people > may extract such a module from the RFC long after it becomes obsolete. > > Please let me know what you think about this. > > > An IANA registry can contain any number of columns meaning an infinite > variety of things - TLS comes to mind. A YANG module is more limited. > Having both in an RFC shows how to map the registry into YANG. Such a module isn't meant as a replacement of the registry, developers will most likely need to consult both. Contents of extra columns may either appear in the description (as in iana-dnssec-algorithms), or may be omitted (as in iana-structured-syntax-suffix). And yes, as I wrote domain experts' input may be needed, perhaps in the form of an RFC. However, it is not ideal to include a complete YANG module (initial revision) based on a random snapshot of the registry in such an RFC. In DNSOP WG this turned out to be a no-go, and after discussing a few alternatives we came up with an XSLT stylesheet as kind of a recipe from which IANA made the initial revision. I understand that XSLT isn't everyone's favourite language, but I don't know about a better choice for this purpose. Perhaps the RFC could just explain the rules for the translation in the text (with examples). > > And what do yo do with Early Allocation, which can last more than a year? Sorry, I am not familiar with early allocations, what could be the problem here? Lada > > Tom Petch > > Thanks, Lada > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
On 2021-11-24, at 09:13, Ladislav Lhotka wrote: > > Please let me know what you think about this. I think it is amazing. So for each registry, you have — manually extracted an information model and kept that in your head, — written code that translates the information you could extract from the XML form of the registry into a YANG data model (note that this data model is not defining the registry, but it is the translated content of the registry) This is certainly highly useful. It also requires to essentially start from scratch for each new registry. Shouldn’t registries come with a machine readable information model? Shouldn’t it then be “easy” to build a generic tool that creates a YANG model out of the data in the registry? Grüße, Carsten ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
From: netmod on behalf of Ladislav Lhotka Sent: 24 November 2021 08:13 Hi, I tried to generalize the approach of RFC 9108 and develop XSLT stylesheets for generating YANG modules directly from IANA registries. The results are in this GitHub project: https://github.com/llhotka/iana-yang So far I have processed 22 registries - most of them are related to DNS, but I also tried to include a few from other areas. After cloning the project, all YANG modules can be generated by running "make" in the top-level directory. Adding a new registry is usually quite simple, although some hide nasty surprises such as duplicate entries. Also, in most cases it is quite clear how to do the translation, but sometimes input from domain experts might be needed. I can see two immediate advantages of this approach: * There is a single source of truth - the registry itself; IANA needn't maintain the YANG module separately. * The initial revision of a registry-based YANG module needn't be published in an RFC that is not intended to be updated. There are concerns that people may extract such a module from the RFC long after it becomes obsolete. Please let me know what you think about this. An IANA registry can contain any number of columns meaning an infinite variety of things - TLS comes to mind. A YANG module is more limited. Having both in an RFC shows how to map the registry into YANG. And what do yo do with Early Allocation, which can last more than a year? Tom Petch Thanks, Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries and YANG
Maybe this approach can be for the algorithms in the "iana-*algs.yang" modules defined in the crypto-types draft. The '*' expands to symmetric, asymmetric, and hash. The problem is that I'm unsure if there is exists 1-1 registries. But, to the extent there are registries, this approach seems easiest for IANA. Kent // contributor > On Dec 18, 2019, at 2:29 AM, Ladislav Lhotka wrote: > > Ladislav Lhotka writes: > >> Hi, >> >> I would like to discuss the issue of developing YANG modules that mirror >> IANA registries. The main objection, raised in DNSOP WG in relation to >> draft-lhotka-dnsop-iana-class-type-yang-02, was that the RFC containing the >> initial revision of the module doesn't get updated along with the IANA >> registry (IANA is expected to keep the module in sync without updating the >> RFC). As a result implementors can use the obsolete snapshot from the RFC. >> >> I am aware of three solution proposals: >> >> 1. use some kind of template instead of a YANG module > > Followup: template turned out to be the right buzzword! Instead of the > initial revision of a YANG module, it is possible to include an XSLT > stylesheet and instruct IANA to use it for generating the initial revision of > the module directly from the XML version of the registry. I used this > approach in > > https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-00 > > Could this be a recommended way for converting other IANA registries? > > Lada > >> >> 2. include only two or three entries of the registry as examples so >> that it is clear that it is not the complete list >> >> 3. keep the module in the document during the whole I-D stage but >> instruct the RFC Editor to remove it just before it becomes RFC. >> >> I am personally in favour of #3. According to Randy Presuhn, who proposed >> it, this procedure was used during the preparation of BCP 47. It would >> require some extra coordination with with IANA but, apart from that, it >> should IMO work well and avoid the problem mentioned above. >> >> Thanks, Lada >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> ___ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries and YANG
Ladislav Lhotka writes: > Hi, > > I would like to discuss the issue of developing YANG modules that mirror IANA > registries. The main objection, raised in DNSOP WG in relation to > draft-lhotka-dnsop-iana-class-type-yang-02, was that the RFC containing the > initial revision of the module doesn't get updated along with the IANA > registry (IANA is expected to keep the module in sync without updating the > RFC). As a result implementors can use the obsolete snapshot from the RFC. > > I am aware of three solution proposals: > > 1. use some kind of template instead of a YANG module Followup: template turned out to be the right buzzword! Instead of the initial revision of a YANG module, it is possible to include an XSLT stylesheet and instruct IANA to use it for generating the initial revision of the module directly from the XML version of the registry. I used this approach in https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-00 Could this be a recommended way for converting other IANA registries? Lada > > 2. include only two or three entries of the registry as examples so >that it is clear that it is not the complete list > > 3. keep the module in the document during the whole I-D stage but >instruct the RFC Editor to remove it just before it becomes RFC. > > I am personally in favour of #3. According to Randy Presuhn, who proposed it, > this procedure was used during the preparation of BCP 47. It would require > some extra coordination with with IANA but, apart from that, it should IMO > work well and avoid the problem mentioned above. > > Thanks, Lada > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries and YANG
On Tue, 2019-11-19 at 11:48 +, tom petch wrote: > - Original Message - > From: "Ladislav Lhotka" > To: "Martin Bjorklund" > Cc: > Sent: Tuesday, November 19, 2019 10:29 AM > > > On Tue, 2019-11-19 at 11:17 +0100, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > > Hi, > > > > > > > > I would like to discuss the issue of developing YANG modules that > > > > mirror IANA registries. The main objection, raised in DNSOP WG in > > > > relation to draft-lhotka-dnsop-iana-class-type-yang-02, was that > the > > > > RFC containing the initial revision of the module doesn't get > updated > > > > along with the IANA registry (IANA is expected to keep the module > in > > > > sync without updating the RFC). As a result implementors can use > the > > > > obsolete snapshot from the RFC. > > > > > > > > I am aware of three solution proposals: > > > > > > > > 1. use some kind of template instead of a YANG module > > > > > > > > 2. include only two or three entries of the registry as examples > so > > > >that it is clear that it is not the complete list > > > > > > > > 3. keep the module in the document during the whole I-D stage but > > > >instruct the RFC Editor to remove it just before it becomes > RFC. > > > Do you mean that the RFC editor removes it and the RFC just points > to > > > the IANA registry? And then the RFC editor hands it over to IANA so > > > that they can use it as an initial version to be published? > > > > Yes. The final RFC would then only describe and explain the design of > the > > module, which is useful in itself (because there are several possible > options > > for translating a registry to YANG). > > > > > As long as the instructions to the RFC editor are clear, I think > this > > > can work. > > > > We have to work out the details and discuss it with IANA, but it > shouldn't IMO > > be too difficult. And the draft in DNSOP can be used as a guinea pig. > > I think that this is a bad idea; we have been handing over modules to > IANA to maintain since 1999 and I have not seen much in the way of > troubles in the intervening decades. I guess everyone in this mailing list will agree that this issue is largely a red herring, but it seems that our draft in DNSOP cannot move forward without solving it. For those with masochistic inclination, here is a typical ML thread: https://mailarchive.ietf.org/arch/msg/dnsop/0AjdiR8htN_vjglimt1b7z10V_E DNSOP chairs don't want to take a stance and hope that the IESG will resolve this issue somehow - but this is of course not going to happen. > > I want the RFC to contain the initial version of the module - otherwise, > we have no record of the initial version. Why do you need the initial version? After all, it is just a random snapshot of the registry that is used to explain to IANA how the module is supposed to be updated. > > What we should do is make it clear that it is the initial version and > will not be maintained e.g. in the description and revision clauses > > 'The initial version of this module was published in RFC; the > current version can be found at > https:// ...iana ... > " I suggested something like this repeatedly, without any significant success. What else can we do? Lada > > Tom Petch > > > > > > > > > > > > > Lada > > > > > > > > > > > /martin > > > > > > > > > > I am personally in favour of #3. According to Randy Presuhn, who > > > > proposed it, this procedure was used during the preparation of BCP > > > > 47. It would require some extra coordination with with IANA but, > apart > > > > from that, it should IMO work well and avoid the problem mentioned > > > > above. > > > > > > > > Thanks, Lada > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > ___ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries and YANG
On Tue, 2019-11-19 at 11:17 +0100, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Hi, > > > > I would like to discuss the issue of developing YANG modules that > > mirror IANA registries. The main objection, raised in DNSOP WG in > > relation to draft-lhotka-dnsop-iana-class-type-yang-02, was that the > > RFC containing the initial revision of the module doesn't get updated > > along with the IANA registry (IANA is expected to keep the module in > > sync without updating the RFC). As a result implementors can use the > > obsolete snapshot from the RFC. > > > > I am aware of three solution proposals: > > > > 1. use some kind of template instead of a YANG module > > > > 2. include only two or three entries of the registry as examples so > >that it is clear that it is not the complete list > > > > 3. keep the module in the document during the whole I-D stage but > >instruct the RFC Editor to remove it just before it becomes RFC. > > Do you mean that the RFC editor removes it and the RFC just points to > the IANA registry? And then the RFC editor hands it over to IANA so > that they can use it as an initial version to be published? Yes. The final RFC would then only describe and explain the design of the module, which is useful in itself (because there are several possible options for translating a registry to YANG). > > As long as the instructions to the RFC editor are clear, I think this > can work. We have to work out the details and discuss it with IANA, but it shouldn't IMO be too difficult. And the draft in DNSOP can be used as a guinea pig. Lada > > > > /martin > > > > > > I am personally in favour of #3. According to Randy Presuhn, who > > proposed it, this procedure was used during the preparation of BCP > > 47. It would require some extra coordination with with IANA but, apart > > from that, it should IMO work well and avoid the problem mentioned > > above. > > > > Thanks, Lada > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries and YANG
Ladislav Lhotka wrote: > Hi, > > I would like to discuss the issue of developing YANG modules that > mirror IANA registries. The main objection, raised in DNSOP WG in > relation to draft-lhotka-dnsop-iana-class-type-yang-02, was that the > RFC containing the initial revision of the module doesn't get updated > along with the IANA registry (IANA is expected to keep the module in > sync without updating the RFC). As a result implementors can use the > obsolete snapshot from the RFC. > > I am aware of three solution proposals: > > 1. use some kind of template instead of a YANG module > > 2. include only two or three entries of the registry as examples so >that it is clear that it is not the complete list > > 3. keep the module in the document during the whole I-D stage but >instruct the RFC Editor to remove it just before it becomes RFC. Do you mean that the RFC editor removes it and the RFC just points to the IANA registry? And then the RFC editor hands it over to IANA so that they can use it as an initial version to be published? As long as the instructions to the RFC editor are clear, I think this can work. /martin > > I am personally in favour of #3. According to Randy Presuhn, who > proposed it, this procedure was used during the preparation of BCP > 47. It would require some extra coordination with with IANA but, apart > from that, it should IMO work well and avoid the problem mentioned > above. > > Thanks, Lada > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
On Mon, 2019-10-21 at 14:54 +, Kent Watsen wrote: > Hi Lada, > > > Another option, also suggested in DNSOP WG, was to enable YANG to refer > > directly to the IANA registry. > > For crypto types, I don’t know if this it possible, as there may be many > registries involved. > > Regardless, what is it that is doing the referring? an identityref? there > needs to be a module update, not just a ref, right? or do you mean that the > type is “string” and the values are documented to be from said IANA > registries? This is of course a good question. I think an implicit enumeration could be a good fit for many registries. > > > > The problem with this is that we have no formalism for writing such > > templates. > > True. > > > > How about preparing an initial revision of the module, without writing any > > > RFC, and hand it over to IANA to be published as a > > > supplement to the registry? > > I don’t understand. Can you give a sketch of what you have in mind? Just prepare the module and run it through some defined approval procedure. The module will become official as soon as IANA publishes it on the "YANG Parameters" page [1]. After that, IANA will update the module each time the registry changes - the instructions for updates may be a part of the module description. But there will be no RFC connected to the module. Lada [1] https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml > > > > Kent > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
Hi Lada, > Another option, also suggested in DNSOP WG, was to enable YANG to refer > directly to the IANA registry. For crypto types, I don’t know if this it possible, as there may be many registries involved. Regardless, what is it that is doing the referring? an identityref? there needs to be a module update, not just a ref, right? or do you mean that the type is “string” and the values are documented to be from said IANA registries? > The problem with this is that we have no formalism for writing such templates. True. >> How about preparing an initial revision of the module, without writing any >> RFC, and hand it over to IANA to be published as a >> supplement to the registry? I don’t understand. Can you give a sketch of what you have in mind? Kent ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
Kent Watsen writes: > All, > >>> That's a bit odd. But perhaps it can be solved by actually not >>> filling in all values in this module, but rather make it a template >>> and instruct IANA to fill it in with the contents of the registry at >>> the time of publication. >> >> OK, so the module template in the RFC couldn't be used at all - this might >> indeed help. > > This is an interesting proposal indeed, and one that may help with the > crypto-types "algorithm" discussion as well. > > Having IANA be able to automatically publish revisions for select > module is something that has been discussed in the past, partially > in NETCONF wrt crypto-types, to eliminate the need for expensive RFC > cycles, for updates that needed as a reaction to other RFCs being > published, which should also have the effect of shortening the time > it takes for those updates to be made. Another option, also suggested in DNSOP WG, was to enable YANG to refer directly to the IANA registry. > > AFAIK, no such relationship with IANA exists currently anywhere > within the IETF. To move this idea forward, the chairs need to > discuss with the AD. It might aid that discussion if there were an > example template module...anyone want to a stab at one? The problem with this is that we have no formalism for writing such templates. > > Should there be an I-D that lays out the framework for the agreement > with IANA, or would each draft (e.g., crypto-types) lay it out just > for itself? Actually, this sounds like what might come out of the > discussion with the AD, but thoughts now are welcome to. How about preparing an initial revision of the module, without writing any RFC, and hand it over to IANA to be published as a supplement to the registry? Lada > > Kent // as co-chair -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
All, >> That's a bit odd. But perhaps it can be solved by actually not >> filling in all values in this module, but rather make it a template >> and instruct IANA to fill it in with the contents of the registry at >> the time of publication. > > OK, so the module template in the RFC couldn't be used at all - this might > indeed help. This is an interesting proposal indeed, and one that may help with the crypto-types "algorithm" discussion as well. Having IANA be able to automatically publish revisions for select module is something that has been discussed in the past, partially in NETCONF wrt crypto-types, to eliminate the need for expensive RFC cycles, for updates that needed as a reaction to other RFCs being published, which should also have the effect of shortening the time it takes for those updates to be made. AFAIK, no such relationship with IANA exists currently anywhere within the IETF. To move this idea forward, the chairs need to discuss with the AD. It might aid that discussion if there were an example template module...anyone want to a stab at one? Should there be an I-D that lays out the framework for the agreement with IANA, or would each draft (e.g., crypto-types) lay it out just for itself? Actually, this sounds like what might come out of the discussion with the AD, but thoughts now are welcome to. Kent // as co-chair___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
On Thu, 2019-10-10 at 14:07 +0200, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Hi, > > > > some of you have probably seen the discussions around > > > > https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02 > > > > We proposed to adopt it as a work item in the DNSOP WG, but despite > > some support this is probably not going to happen. The substantial > > objections are: > > > > 1. It is not good to publish a YANG snapshot of an IANA registry as an RFC > > because future implementors will use the module from that RFC and implement > > registry entries that may have been deprecated in the mean time. > > > > 2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC > > 8126) differs from the definition in RFC 7950. > > > > I already raised #2 in this mailing list, and I think it should be > > addressed in the next version of YANG. > > > > Regarding #1, I tried to explain that the RFC is only intended to contain an > > initial revision of the corresponding YANG module, but it didn't help. One > > suggestion was to avoid representing the registries as enumerations or sets > of > > identities, and use only integers. > > That's a bit odd. But perhaps it can be solved by actually not > filling in all values in this module, but rather make it a template > and instruct IANA to fill it in with the contents of the registry at > the time of publication. OK, so the module template in the RFC couldn't be used at all - this might indeed help. My idea was to tag the RFC as historic as soon as IANA takes over the module maintenance. I think part of the problem is that the new revisions are available from a rather obscure place - the YANG Parameters registry page: https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml Lada > > > > /martin > > > > I wonder if we can come up with a reasonable solution. Without > > having the important registries as YANG modules, it is difficult to > > work on other modules - for DNS, in this case, but it could apply to > > other areas, too. > > > > Thanks, Lada > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries
Ladislav Lhotka wrote: > Hi, > > some of you have probably seen the discussions around > > https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02 > > We proposed to adopt it as a work item in the DNSOP WG, but despite > some support this is probably not going to happen. The substantial > objections are: > > 1. It is not good to publish a YANG snapshot of an IANA registry as an RFC > because future implementors will use the module from that RFC and implement > registry entries that may have been deprecated in the mean time. > > 2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC > 8126) differs from the definition in RFC 7950. > > I already raised #2 in this mailing list, and I think it should be > addressed in the next version of YANG. > > Regarding #1, I tried to explain that the RFC is only intended to contain an > initial revision of the corresponding YANG module, but it didn't help. One > suggestion was to avoid representing the registries as enumerations or sets of > identities, and use only integers. That's a bit odd. But perhaps it can be solved by actually not filling in all values in this module, but rather make it a template and instruct IANA to fill it in with the contents of the registry at the time of publication. /martin > I wonder if we can come up with a reasonable solution. Without > having the important registries as YANG modules, it is difficult to > work on other modules - for DNS, in this case, but it could apply to > other areas, too. > > Thanks, Lada > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
